Hey guys I''ve been beating my head on this for a few hours. Maybe it is just a stupid configuration error you can point me at. First here is a small diagram of what I am trying to configure: http://6bit.com/img/netdiag.png Currently I only have Shorewall running on the host on the right of the diagram until I can get this working then I''ll add it to the other host as well. I''ve read the docs on GRE/IPIP tunneling and the docs on IPSec transport with the 2.6 kernel. I''ve been able to get the IPSec transport connection set up successfully and the ESP packets are successfully flowing through the firewall. I am running Kernel 2.6.18, Shorewall 3.2.4, iptables 1.3.5, and iproute iproute2-ss060323. The problem is that I can''t get the GRE packets to make it through the firewall. Any time I try to pass traffic I get (on the righthand host in the diagram): Jan 4 10:53:47 slc-gw-01 Shorewall:INPUT:REJECT:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 I even went as far as putting a rule (ACCEPT inet:67.42.31.242 $FW 47) instead of the entry in the tunnels file with the same result. Here are my config files (the only ones I have edited): /etc/shorewall/zones ---------------------------------------------------------------------- fw firewall evl inet local ---------------------------------------------------------------------- /etc/shorewall/interfaces ---------------------------------------------------------------------- local eth0 10.0.0.0/24 evl vpn1 192.168.0.0/24,192.168.254.4/31 inet vlan4 - ---------------------------------------------------------------------- /etc/shorewall/tunnels ---------------------------------------------------------------------- gre inet 67.42.31.242 ipsec:noah inet 67.42.31.242 ---------------------------------------------------------------------- /etc/shorewall/rules ---------------------------------------------------------------------- SECTION NEW ACCEPT inet $FW tcp ssh ACCEPT local $FW tcp ssh #Firewall PINHOLES ACCEPT $FW local udp name ---------------------------------------------------------------------- /etc/shorewall/policy ---------------------------------------------------------------------- $FW all ACCEPT local $FW ACCEPT #Branch Office VPN Rules local evl ACCEPT evl local ACCEPT #INTERNET RULES local inet ACCEPT inet all DROP info #DEFAULT DROP everything rule all all REJECT info ---------------------------------------------------------------------- I''m not sure what to do at this point, I''m not really an iptables guru (hence shorewall) so I don''t know if maybe it is how netfilter is seeing the GRE packets since they already have been through netfilter once because of the ESP though the log says in=vlan4 which is correct. Any pointers are appreciated, and If I can get this I''d love to maybe write a how-to on doing IPSec secured GRE tunnels with Shorewall. Thanks Joshua Perry ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Some other info as I try to diagnose this. I am using Gentoo 2006.1 and the network scripts that come with it to setup the tunnel as well as raccoon and ipsec-tools to setup the ipsec encryption. Here is a trace (I used this bash script http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html) of a simple ping over the GRE tunnel. Also, as chance would have it you can see a GRE packet successfully leaving the same host enroute to where one was just dropped from (I realize the paths are not symmetrical, just thought it may reveal some useful information). Jan 4 11:52:49 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:vlan4_in:3:inet2fw:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:inet2fw:1:ACCEPT:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:vlan4_in:1:dynamic:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:INPUT:9:Reject:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:Reject:3:dropBcast:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:Reject:9:dropInvalid:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:INPUT:11:reject:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:reject:37:REJECT --rejec:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:OUTPUT:9:ACCEPT:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=140 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ICMP TYPE=3 CODE=10 [SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 ] Jan 4 11:52:49 slc-gw-01 *f:OUTPUT:5:fw2inet:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=184 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ESP SPI=0xcca9021 Jan 4 11:52:49 slc-gw-01 *f:fw2inet:1:ACCEPT:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=184 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ESP SPI=0xcca9021 Josh -----Original Message----- From: Joshua Perry [mailto:josh@6bit.com] Sent: Thursday, January 04, 2007 5:11 PM To: ''shorewall-users@lists.sourceforge.net'' Subject: GRE over IPSec VPN Hey guys I''ve been beating my head on this for a few hours. Maybe it is just a stupid configuration error you can point me at. First here is a small diagram of what I am trying to configure: http://6bit.com/img/netdiag.png Currently I only have Shorewall running on the host on the right of the diagram until I can get this working then I''ll add it to the other host as well. I''ve read the docs on GRE/IPIP tunneling and the docs on IPSec transport with the 2.6 kernel. I''ve been able to get the IPSec transport connection set up successfully and the ESP packets are successfully flowing through the firewall. I am running Kernel 2.6.18, Shorewall 3.2.4, iptables 1.3.5, and iproute iproute2-ss060323. The problem is that I can''t get the GRE packets to make it through the firewall. Any time I try to pass traffic I get (on the righthand host in the diagram): Jan 4 10:53:47 slc-gw-01 Shorewall:INPUT:REJECT:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 I even went as far as putting a rule (ACCEPT inet:67.42.31.242 $FW 47) instead of the entry in the tunnels file with the same result. Here are my config files (the only ones I have edited): /etc/shorewall/zones ---------------------------------------------------------------------- fw firewall evl inet local ---------------------------------------------------------------------- /etc/shorewall/interfaces ---------------------------------------------------------------------- local eth0 10.0.0.0/24 evl vpn1 192.168.0.0/24,192.168.254.4/31 inet vlan4 - ---------------------------------------------------------------------- /etc/shorewall/tunnels ---------------------------------------------------------------------- gre inet 67.42.31.242 ipsec:noah inet 67.42.31.242 ---------------------------------------------------------------------- /etc/shorewall/rules ---------------------------------------------------------------------- SECTION NEW ACCEPT inet $FW tcp ssh ACCEPT local $FW tcp ssh #Firewall PINHOLES ACCEPT $FW local udp name ---------------------------------------------------------------------- /etc/shorewall/policy ---------------------------------------------------------------------- $FW all ACCEPT local $FW ACCEPT #Branch Office VPN Rules local evl ACCEPT evl local ACCEPT #INTERNET RULES local inet ACCEPT inet all DROP info #DEFAULT DROP everything rule all all REJECT info ---------------------------------------------------------------------- I''m not sure what to do at this point, I''m not really an iptables guru (hence shorewall) so I don''t know if maybe it is how netfilter is seeing the GRE packets since they already have been through netfilter once because of the ESP though the log says in=vlan4 which is correct. Any pointers are appreciated, and If I can get this I''d love to maybe write a how-to on doing IPSec secured GRE tunnels with Shorewall. Thanks Joshua Perry ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Alright, it looks like the packet is not matching this rule in the vlan4_in chain: 16 2624 inet2fw all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol none So it is not getting a chance to be accepted by the inet2fw chain which is where the rule is to accept GRE packets from the other host and duly getting dropped by the default Reject chain in INPUT. Is there some reason that GRE packets that were encapsulated in IPSec are not seen as inbound? Is this an accurate assumption? Is there a way to fix this? Thanks again, Josh -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Joshua Perry Sent: Thursday, January 04, 2007 6:10 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] GRE over IPSec VPN Some other info as I try to diagnose this. I am using Gentoo 2006.1 and the network scripts that come with it to setup the tunnel as well as raccoon and ipsec-tools to setup the ipsec encryption. Here is a trace (I used this bash script http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html) of a simple ping over the GRE tunnel. Also, as chance would have it you can see a GRE packet successfully leaving the same host enroute to where one was just dropped from (I realize the paths are not symmetrical, just thought it may reveal some useful information). Jan 4 11:52:49 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:vlan4_in:3:inet2fw:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:inet2fw:1:ACCEPT:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xa249b63 Jan 4 11:52:49 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:vlan4_in:1:dynamic:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:INPUT:9:Reject:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:Reject:3:dropBcast:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:Reject:9:dropInvalid:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:INPUT:11:reject:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:reject:37:REJECT --rejec:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 Jan 4 11:52:49 slc-gw-01 *f:OUTPUT:9:ACCEPT:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=140 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ICMP TYPE=3 CODE=10 [SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 ] Jan 4 11:52:49 slc-gw-01 *f:OUTPUT:5:fw2inet:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=184 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ESP SPI=0xcca9021 Jan 4 11:52:49 slc-gw-01 *f:fw2inet:1:ACCEPT:IN= OUT=vlan4 SRC=166.70.106.148 DST=67.42.31.242 LEN=184 TOS=0x00 PREC=0xC0 TTL=64 ID=9816 PROTO=ESP SPI=0xcca9021 Josh -----Original Message----- From: Joshua Perry [mailto:josh@6bit.com] Sent: Thursday, January 04, 2007 5:11 PM To: ''shorewall-users@lists.sourceforge.net'' Subject: GRE over IPSec VPN Hey guys I''ve been beating my head on this for a few hours. Maybe it is just a stupid configuration error you can point me at. First here is a small diagram of what I am trying to configure: http://6bit.com/img/netdiag.png Currently I only have Shorewall running on the host on the right of the diagram until I can get this working then I''ll add it to the other host as well. I''ve read the docs on GRE/IPIP tunneling and the docs on IPSec transport with the 2.6 kernel. I''ve been able to get the IPSec transport connection set up successfully and the ESP packets are successfully flowing through the firewall. I am running Kernel 2.6.18, Shorewall 3.2.4, iptables 1.3.5, and iproute iproute2-ss060323. The problem is that I can''t get the GRE packets to make it through the firewall. Any time I try to pass traffic I get (on the righthand host in the diagram): Jan 4 10:53:47 slc-gw-01 Shorewall:INPUT:REJECT:IN=vlan4 OUTMAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47 I even went as far as putting a rule (ACCEPT inet:67.42.31.242 $FW 47) instead of the entry in the tunnels file with the same result. Here are my config files (the only ones I have edited): /etc/shorewall/zones ---------------------------------------------------------------------- fw firewall evl inet local ---------------------------------------------------------------------- /etc/shorewall/interfaces ---------------------------------------------------------------------- local eth0 10.0.0.0/24 evl vpn1 192.168.0.0/24,192.168.254.4/31 inet vlan4 - ---------------------------------------------------------------------- /etc/shorewall/tunnels ---------------------------------------------------------------------- gre inet 67.42.31.242 ipsec:noah inet 67.42.31.242 ---------------------------------------------------------------------- /etc/shorewall/rules ---------------------------------------------------------------------- SECTION NEW ACCEPT inet $FW tcp ssh ACCEPT local $FW tcp ssh #Firewall PINHOLES ACCEPT $FW local udp name ---------------------------------------------------------------------- /etc/shorewall/policy ---------------------------------------------------------------------- $FW all ACCEPT local $FW ACCEPT #Branch Office VPN Rules local evl ACCEPT evl local ACCEPT #INTERNET RULES local inet ACCEPT inet all DROP info #DEFAULT DROP everything rule all all REJECT info ---------------------------------------------------------------------- I''m not sure what to do at this point, I''m not really an iptables guru (hence shorewall) so I don''t know if maybe it is how netfilter is seeing the GRE packets since they already have been through netfilter once because of the ESP though the log says in=vlan4 which is correct. Any pointers are appreciated, and If I can get this I''d love to maybe write a how-to on doing IPSec secured GRE tunnels with Shorewall. Thanks Joshua Perry ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Thu, Jan 04, 2007 at 05:11:07PM -0700, Joshua Perry wrote:> I''m not sure what to do at this pointConsider using openvpn instead? Chances are it does everything you need and would be far less work to set up (the firewall rules are trivial; the openvpn config files can be understood in less than an hour and take about five minutes to write, and then it should be working). You didn''t say, but since your diagram shows a pair of private networks, I''m assuming that you control both endpoints and aren''t trying to connect to somebody else''s insanity (if you are, I can only offer my condolences, ipsec+GRE is about as bad as it gets). I''m not sure why people always leap for ipsec, it''s probably the most complicated option available - only the most fiendishly sophisticated systems need it, it is sheer masochism for everybody else. And if you''re using linux instead of a cisco router, it''s pretty unlikely that you need to be using GRE for anything. Perhaps it would help if all the pages on shorewall.net relating to ipsec, pptp, and any other tunneling protocols had a big banner on the top saying: ************************************************************************ * ____ _____ ___ ____ * * / ___|_ _/ _ \| _ \ * * \___ \ | || | | | |_) | * * ___) || || |_| | __/ * * |____/ |_| \___/|_| * * * * If you just want to hook two linux systems together with a VPN over * * the Internet, this is almost certainly overkill. Consider reading * * http://shorewall.net/OPENVPN.html instead, it''s much easier. * ************************************************************************ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> Alright, it looks like the packet is not matching this rule in the vlan4_in > chain: > 16 2624 inet2fw all -- * * 0.0.0.0/0 > 0.0.0.0/0 policy match dir in pol none >No packet that has come through an kernel 2.6 IPSEC tunnel will EVER match that rule. I assume that GRE is being tunneled through an ah/esp/... IPSEC tunnel? You''ve only shown us a smattering of your config files and you didn''t include a Shorewall dump but it looks like you probably haven''t defined your IPSEC zone(s) correctly. The word ''ipsec'' only appeared in the tunnels file among those files you thought were important enough to quote. You need an ipsec zone or an ipsec host group to represent the hosts at the other end of the tunnel. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> /etc/shorewall/tunnels > ---------------------------------------------------------------------- > gre inet 67.42.31.242 > ipsec:noah inet 67.42.31.242 > ----------------------------------------------------------------------The above defines parallel tunnels! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
I realize that no packets will match that, that''s why I am confused why that is what is generated by shorewall in the interface input chain. I quoted all of the config files that I made changes to not merely the ones that I thought were important. I don''t need a zone for IPSec because I am using GRE for tunneling the IPSec connection is strictly transport mode, no AH and no need for setting policies or rules for the 2 hosts involved in the transport mode connection.>From the documentation I was under the impression that an entry in tunnelsis all that is needed to get the firewall opened up for IPSec, and in fact thanks to the documentation the IPSec transport is working fine. I do however have a zone setup for the GRE tunnel and the requisite interface and policy entries for that subnet. The ESP packets successfully transverse the inet2fw chain and are accepted there. Once the packet is unwrapped it then hits the INPUT again and gets rejected because the unwrapped GRE packet (correct me if I''m wrong) no longer matches "dir in" in that rule. I verified this by creating an identical rule sans the policy match to the one below and was able to pass traffic. The other thing I also get to look forward to is another pass through the chains once the packet inside the GRE packet is unwrapped. That packet also does not match that rule below and hence will not get a chance to be accepted inside of the inet2fw chain. I''ve attached a shorewall dump so you can see everything. Thanks for the assistance! Josh -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, January 04, 2007 7:49 PM To: Shorewall Users Subject: Re: [Shorewall-users] GRE over IPSec VPN Joshua Perry wrote:> Alright, it looks like the packet is not matching this rule in the > vlan4_in > chain: > 16 2624 inet2fw all -- * * 0.0.0.0/0 > 0.0.0.0/0 policy match dir in pol none >No packet that has come through an kernel 2.6 IPSEC tunnel will EVER match that rule. I assume that GRE is being tunneled through an ah/esp/... IPSEC tunnel? You''ve only shown us a smattering of your config files and you didn''t include a Shorewall dump but it looks like you probably haven''t defined your IPSEC zone(s) correctly. The word ''ipsec'' only appeared in the tunnels file among those files you thought were important enough to quote. You need an ipsec zone or an ipsec host group to represent the hosts at the other end of the tunnel. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
The ipsec:noah entry is merely to allow ESP packets for the transport mode ipsec encryption between the hosts. The gre entry is to allow protocol 47 packets from that host also, because once the ESP is unwrapped that is what is inside, with the same source address. Your documentation itself says that the tunnels file is to be replaced some day with entries in the rules table so I am merely using the ipsec:noah entry in the tunnels table as a macro of sorts to replace this in the rules table (which is indeed generated and works fine): ACCEPT $FW inet:67.42.31.242 udp 500 ACCEPT inet:67.42.31.242 $FW udp 500 ACCEPT $FW inet:67.42.31.242 esp ACCEPT inet:67.42.31.242 $FW esp Also the documentation says about the tunnels file "(don''t be mislead by the name of the file -- transport mode encrypted traffic is also handled by entries in that file)" and that''s exactly what I''m using the ipsec:noah entry for in the tunnels file just a transport mode connection. Josh -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, January 04, 2007 8:06 PM To: Shorewall Users Subject: Re: [Shorewall-users] GRE over IPSec VPN Joshua Perry wrote:> /etc/shorewall/tunnels > ---------------------------------------------------------------------- > gre inet 67.42.31.242 > ipsec:noah inet 67.42.31.242 > ----------------------------------------------------------------------The above defines parallel tunnels! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hey Andrew, OpenVPN sounds interesting, and I did breeze past it a couple times while researching branch office vpn solutions. There are a couple reasons that I went with IPSec, I don''t know if they really hold any weight, but here is my thought pattern. -GRE/IPSec is pretty industry standard at this point, our cisco gear supports it, our Watchguard supports it, so if I needed to I would be able to support something besides a remote pc host. -Besides the IKE the encryption is done in kernel mode which is bound to improve throughput, I don''t know if that is really a bottleneck with our infrastructure so it''s something that I would love to benchmark against OpenVPN. We do a lot of large file transfers as we are a large format digital print company (billboards, trade show booths, etc...). -GRE an IPSec are integrated in the OS pretty tightly, not just the Kernel support but it is also supported natively by Gentoo''s network setup scripts. -It is simple :) perhaps not as simple as OpenVPN to setup, but simple as in not quite as overkill as OpenVPN, I merely wanted to encrypt data between two hosts, the setup definitely was not OE but it didn''t take more than 30 minutes to configure. Once that worked, the GRE tunnel went up in another 5 minutes and really transport mode IPSec is pretty transparent to the GRE tunnel. I was passing and routing traffic with no problems. So it kind of fit my requirements better, not that OpenVPN doesn''t which I will probably give a try, but it seemed a better fit. The problem didn''t come until I wanted to put a firewall up to secure the box against the harsh internet. I decided to try shorewall because I didn''t really want to manage iptables chains by hand and that is where I have been having problems. I first tried intersecting the IPSec and the GRE tutorial documents and then I have been trying to understand how shorewall translates it''s zone/policies/interfaces into IPTables rules and chains as I was not able to find any information specifically on opening up IPSec protected GRE anywhere. So, I guess this may over all be a configuration that is not supported by shorewall. If that is the case I guess I have the options of managing the chains by hand or using OpenVPN instead of GRE over IPSec. Thank you for the input. Josh -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Andrew Suffield Sent: Thursday, January 04, 2007 7:43 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] GRE over IPSec VPN On Thu, Jan 04, 2007 at 05:11:07PM -0700, Joshua Perry wrote:> I''m not sure what to do at this pointConsider using openvpn instead? Chances are it does everything you need and would be far less work to set up (the firewall rules are trivial; the openvpn config files can be understood in less than an hour and take about five minutes to write, and then it should be working). You didn''t say, but since your diagram shows a pair of private networks, I''m assuming that you control both endpoints and aren''t trying to connect to somebody else''s insanity (if you are, I can only offer my condolences, ipsec+GRE is about as bad as it gets). I''m not sure why people always leap for ipsec, it''s probably the most complicated option available - only the most fiendishly sophisticated systems need it, it is sheer masochism for everybody else. And if you''re using linux instead of a cisco router, it''s pretty unlikely that you need to be using GRE for anything. Perhaps it would help if all the pages on shorewall.net relating to ipsec, pptp, and any other tunneling protocols had a big banner on the top saying: ************************************************************************ * ____ _____ ___ ____ * * / ___|_ _/ _ \| _ \ * * \___ \ | || | | | |_) | * * ___) || || |_| | __/ * * |____/ |_| \___/|_| * * * * If you just want to hook two linux systems together with a VPN over * * the Internet, this is almost certainly overkill. Consider reading * * http://shorewall.net/OPENVPN.html instead, it''s much easier. * ************************************************************************ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> The ipsec:noah entry is merely to allow ESP packets for the transport mode > ipsec encryption between the hosts. The gre entry is to allow protocol 47 > packets from that host also, because once the ESP is unwrapped that is what > is inside, with the same source address. > > Your documentation itself says that the tunnels file is to be replaced some > day with entries in the rules table so I am merely using the ipsec:noah > entry in the tunnels table as a macro of sorts to replace this in the rules > table (which is indeed generated and works fine): > > ACCEPT $FW inet:67.42.31.242 udp 500 > ACCEPT inet:67.42.31.242 $FW udp 500 > ACCEPT $FW inet:67.42.31.242 esp > ACCEPT inet:67.42.31.242 $FW esp > > Also the documentation says about the tunnels file "(don''t be mislead by the > name of the file -- transport mode encrypted traffic is also handled by > entries in that file)" and that''s exactly what I''m using the ipsec:noah > entry for in the tunnels file just a transport mode connectionJoshua, I don''t have the time or energy to explain this to you tonight or to look at your dump. I''ve been up since 4:30 this morning, it''s going on 8PM and I still have a conference call to handle before I go to bed. But what you have defined is two parallel tunnels rather than a GRE tunnel inside of an IPSEC transport SA. The gateway zone for one tunnels file entry or the other is not ''inet''. I suspect that it is the GRE tunnel whose gateway is in the ipsec zone (whatever that is) since I assume that you are encrypting the GRE packets with an IPSEC transport mode SA. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> > So, I guess this may over all be a configuration that is not supported by > shorewall. If that is the case I guess I have the options of managing the > chains by hand or using OpenVPN instead of GRE over IPSec.At least if you manage the chains by hand, you''ll eventually learn out how it works -- then it will be obvious how to handle it in Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>From experience and what I''ve read, IPSEC is easy to setup and workwith where there is no natting/firewalling. Where there is natting/firewalling IPSEC or the firewall/nat is not so trivial to setup. Your choice is based on the amount of time you are ready to spend. In this two site-scenario, I can bet that OpenVPN would take less than 1hr from scratch! And as Tom has said in his two mails IPSEC/GRE is not so simple in theory either! *Just a very happy user of OpenVPN* Ditched IPSEC after about a week of effort to setup IPSEC in all our required scenarios. Then was in awe when I managed to do the same within 1 hour with OpenVPN from scratch (reading the documentation included). Never looked back. Prasanna. On 1/5/07, Joshua Perry <josh@6bit.com> wrote:> Hey Andrew, OpenVPN sounds interesting, and I did breeze past it a couple > times while researching branch office vpn solutions. There are a couple > reasons that I went with IPSec, I don''t know if they really hold any weight, > but here is my thought pattern. > > -GRE/IPSec is pretty industry standard at this point, our cisco gear > supports it, our Watchguard supports it, so if I needed to I would be able > to support something besides a remote pc host. > > -Besides the IKE the encryption is done in kernel mode which is bound to > improve throughput, I don''t know if that is really a bottleneck with our > infrastructure so it''s something that I would love to benchmark against > OpenVPN. We do a lot of large file transfers as we are a large format > digital print company (billboards, trade show booths, etc...). > > -GRE an IPSec are integrated in the OS pretty tightly, not just the Kernel > support but it is also supported natively by Gentoo''s network setup scripts. > > -It is simple :) perhaps not as simple as OpenVPN to setup, but simple as in > not quite as overkill as OpenVPN, I merely wanted to encrypt data between > two hosts, the setup definitely was not OE but it didn''t take more than 30 > minutes to configure. Once that worked, the GRE tunnel went up in another 5 > minutes and really transport mode IPSec is pretty transparent to the GRE > tunnel. I was passing and routing traffic with no problems. > > So it kind of fit my requirements better, not that OpenVPN doesn''t which I > will probably give a try, but it seemed a better fit. The problem didn''t > come until I wanted to put a firewall up to secure the box against the harsh > internet. I decided to try shorewall because I didn''t really want to manage > iptables chains by hand and that is where I have been having problems. I > first tried intersecting the IPSec and the GRE tutorial documents and then I > have been trying to understand how shorewall translates it''s > zone/policies/interfaces into IPTables rules and chains as I was not able to > find any information specifically on opening up IPSec protected GRE > anywhere. > > So, I guess this may over all be a configuration that is not supported by > shorewall. If that is the case I guess I have the options of managing the > chains by hand or using OpenVPN instead of GRE over IPSec. > > Thank you for the input. > > Josh > > -----Original Message----- > From: shorewall-users-bounces@lists.sourceforge.net > [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Andrew > Suffield > Sent: Thursday, January 04, 2007 7:43 PM > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] GRE over IPSec VPN > > On Thu, Jan 04, 2007 at 05:11:07PM -0700, Joshua Perry wrote: > > I''m not sure what to do at this point > > Consider using openvpn instead? Chances are it does everything you > need and would be far less work to set up (the firewall rules are > trivial; the openvpn config files can be understood in less than an > hour and take about five minutes to write, and then it should be > working). > > You didn''t say, but since your diagram shows a pair of private > networks, I''m assuming that you control both endpoints and aren''t > trying to connect to somebody else''s insanity (if you are, I can only > offer my condolences, ipsec+GRE is about as bad as it gets). > > > I''m not sure why people always leap for ipsec, it''s probably the most > complicated option available - only the most fiendishly sophisticated > systems need it, it is sheer masochism for everybody else. And if > you''re using linux instead of a cisco router, it''s pretty unlikely > that you need to be using GRE for anything. > > Perhaps it would help if all the pages on shorewall.net relating to > ipsec, pptp, and any other tunneling protocols had a big banner on the > top saying: > > ************************************************************************ > * ____ _____ ___ ____ * > * / ___|_ _/ _ \| _ \ * > * \___ \ | || | | | |_) | * > * ___) || || |_| | __/ * > * |____/ |_| \___/|_| * > * * > * If you just want to hook two linux systems together with a VPN over * > * the Internet, this is almost certainly overkill. Consider reading * > * http://shorewall.net/OPENVPN.html instead, it''s much easier. * > ************************************************************************ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Prasanna Krishnamoorthy wrote:>>From experience and what I''ve read, IPSEC is easy to setup and work > with where there is no natting/firewalling. > > Where there is natting/firewalling IPSEC or the firewall/nat is not so > trivial to setup. > > Your choice is based on the amount of time you are ready to spend. In > this two site-scenario, I can bet that OpenVPN would take less than > 1hr from scratch! > > And as Tom has said in his two mails IPSEC/GRE is not so simple in > theory either! > > *Just a very happy user of OpenVPN* > > Ditched IPSEC after about a week of effort to setup IPSEC in all our > required scenarios. Then was in awe when I managed to do the same > within 1 hour with OpenVPN from scratch (reading the documentation > included). Never looked back.For more reading on this subject, see the recent thread on this list entitled "shorewall + ipsec openswan". That user was doing IPIP tunneling through IPSEC and was going crazy with rejected packets. It took him a long time to finally understand what was happening and to configure the appropriate simple rules. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Thu, Jan 04, 2007 at 08:46:24PM -0700, Joshua Perry wrote:> -GRE/IPSec is pretty industry standard at this point, our cisco gear > supports it, our Watchguard supports it, so if I needed to I would be able > to support something besides a remote pc host.This is possibly the only good reason for using ipsec for something - compatibility with stuff like cisco kit. So maybe you do have reason for the pain. It''s still not a reason to use GRE (that''s intended for a provider-client relationship, where the client doesn''t know about the guts of the provider''s network). ipsec alone would probably suffice.> So, I guess this may over all be a configuration that is not supported by > shorewall. If that is the case I guess I have the options of managing the > chains by hand or using OpenVPN instead of GRE over IPSec.Oh, you can almost certainly get it to work with shorewall - it''s just needlessly difficult to understand and debug the thing. The issue is not whether it''s possible, but whether it''s worth the effort. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Well, it wasn''t too difficult, it is running right now, and added masq
from
the remote site through this host in just 5 minutes. The problem I''ve
found
is the policy match that Shorewall is adding to the interface''s zone
chain
rules "policy match dir in pol none" (eg. rule 2 in vlan4_in) lets ESP
through, then blocks the GRE but never gets stripped to the raw data packets
because it is rejected.
If I add -- like you see below -- the 3rd rule everything works great; ESP
gets in through rule 2 and once in inet2fw there gets accepted by rule 3.
GRE then gets pulled from the ESP and gets through vpn4_1 to inet2fw through
rule 3 and accepted by rule 5, then the raw data gets stripped and shows up
in INPUT as IN=vpn1 and sent down the vpn1_in chain and via rule 2 into
evl2fw and accepted there because of evl2fw''s generous rules.
There is obviously a bit of a dichotomy with how netfilter reacts to the
packets. Basically it deems ESP packets a match to the inbound policy, not
GRE, but the raw packets again are accepted by the policy match. With just
rule 1 & 2 in vlan4_in (default generated by Shorewall) the setup
doesn''t
work, but adding by hand with iptables rule 3 (Or replacing rule 2 with rule
3) everything works great.
I''ve made a quick post to the netfilter list to see if maybe
it''s a bug or
if that is how it is supposed to work. If it turns out not to be a bug I
need to find a way to make Shorewall not put that policy match on the zone
rules, as well as understand why it is there in the first place.
Chain vlan4_in (1 references)
pkts bytes target prot opt in out source
destination
12 1265 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
3617 652K inet2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
3543 476K inet2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain inet2fw (2 references)
pkts bytes target prot opt in out source
destination
7484 1185K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22
0 0 ACCEPT esp -- * * 67.42.31.242
0.0.0.0/0
0 0 ACCEPT udp -- * * 67.42.31.242
0.0.0.0/0 udp dpt:500
0 0 ACCEPT 47 -- * * 67.42.31.242
0.0.0.0/0
12 1265 inet2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain vpn1_in (1 references)
pkts bytes target prot opt in out source
destination
3 228 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
311 24516 evl2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
Chain evl2fw (1 references)
pkts bytes target prot opt in out source
destination
341 26724 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
3 228 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Josh
-----Original Message-----
From: shorewall-users-bounces@lists.sourceforge.net
[mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Andrew
Suffield
Sent: Friday, January 05, 2007 12:57 AM
To: shorewall-users@lists.sourceforge.net
Subject: Re: [Shorewall-users] GRE over IPSec VPN
On Thu, Jan 04, 2007 at 08:46:24PM -0700, Joshua Perry
wrote:> -GRE/IPSec is pretty industry standard at this point, our cisco gear
> supports it, our Watchguard supports it, so if I needed to I would be able
> to support something besides a remote pc host.
This is possibly the only good reason for using ipsec for something -
compatibility with stuff like cisco kit. So maybe you do have reason
for the pain. It''s still not a reason to use GRE (that''s
intended for
a provider-client relationship, where the client doesn''t know about
the guts of the provider''s network). ipsec alone would probably
suffice.
> So, I guess this may over all be a configuration that is not supported by
> shorewall. If that is the case I guess I have the options of managing the
> chains by hand or using OpenVPN instead of GRE over IPSec.
Oh, you can almost certainly get it to work with shorewall - it''s just
needlessly difficult to understand and debug the thing. The issue is
not whether it''s possible, but whether it''s worth the effort.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> Well, it wasn''t too difficult, it is running right now, and added masq from > the remote site through this host in just 5 minutes. The problem I''ve found > is the policy match that Shorewall is adding to the interface''s zone chain > rules "policy match dir in pol none" (eg. rule 2 in vlan4_in) lets ESP > through, then blocks the GRE but never gets stripped to the raw data packets > because it is rejected. > > If I add -- like you see below -- the 3rd rule everything works great; ESP > gets in through rule 2 and once in inet2fw there gets accepted by rule 3. > GRE then gets pulled from the ESP and gets through vpn4_1 to inet2fw through > rule 3 and accepted by rule 5, then the raw data gets stripped and shows up > in INPUT as IN=vpn1 and sent down the vpn1_in chain and via rule 2 into > evl2fw and accepted there because of evl2fw''s generous rules. > > There is obviously a bit of a dichotomy with how netfilter reacts to the > packets. Basically it deems ESP packets a match to the inbound policy, not > GRE, but the raw packets again are accepted by the policy match. With just > rule 1 & 2 in vlan4_in (default generated by Shorewall) the setup doesn''t > work, but adding by hand with iptables rule 3 (Or replacing rule 2 with rule > 3) everything works great. > > I''ve made a quick post to the netfilter list to see if maybe it''s a bug or > if that is how it is supposed to work. If it turns out not to be a bug I > need to find a way to make Shorewall not put that policy match on the zone > rules, as well as understand why it is there in the first place.Once again, this is not a bug but rather your lack of understanding about what is going on. There are three broad classes of Shorewall zones: a) firewall b) ipv4 c) ipsec The type of zone is specified in the second column of /etc/shorewall/zones. Zones of type ''ipv4'' may have ipsec "groups" included in them. A host group is designated as being ''ipsec'' by including the keyword "ipsec" in the OPTIONS column of /etc/shorewall/hosts. Traffic to/from ipv4 zones is not encrypted by IPSEC. Traffic to/from ipsec zones and/or ipsec host groups is encrypted. Here is what you claim to be your zones file: /etc/shorewall/zones ---------------------------------------------------------------------- fw firewall evl inet local ---------------------------------------------------------------------- You have no ''ipsec'' zones. From looking at the dump that you supplied last night, I see that you have no ipsec host groups. In iptables terms then, your ''inet'' zone is not an ipsec zone so traffic to/from hosts in that zone is not encrypted. That is why this rule is the way that it is: 16 2624 inet2fw all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol none The ''pol none'' says that only traffic from inet hosts that has not been decrypted should pass through that chain. Now if you would have added this to your /etc/shorewall/zones file: rem ipsec and this to your /etc/shorewall/zones file: rem vlan4 - Then you would have seen a rule in the vlan4_in chain such as follows: xx yyyy rem2fw all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec An traffic entering on vlan4 would have been passed through the rem2fw chain. ----------------------------------------------------------------------- Note: Alternatively, you could put this in /etc/shorewallzones: rem ipv4 And this in /etc/shorewall/hosts: rem vlan4:67.42.31.242 ipsec ----------------------------------------------------------------------- Finally, in the /etc/shorewall/tunnels file, you have: /etc/shorewall/tunnels ---------------------------------------------------------------------- gre inet 67.42.31.242 ipsec:noah inet 67.42.31.242 ---------------------------------------------------------------------- The GRE traffic is subject to the IPSEC transport mode SA. So by the time that GRE packets are processed by the Shorewall-generated ruleset, they have been decrypted. As you''ve pointed out, they don''t get sent down the ''inet2fw'' chain but they *would* be sent down the ''rem2fw'' chain. So the first tunnels file entry should be: gre rem 67.42.31.242 That is what I meant about parallel vs. nested tunnels -- the GRE tunnel is nested within the IPSEC transport mode SA and must be defined accordingly. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> > Then you would have seen a rule in the vlan4_in chain such as follows: > > xx yyyy rem2fw all -- * * 0.0.0.0/0 > 0.0.0.0/0 policy match dir in pol ipsec > > An traffic entering on vlan4 would have been passed through the rem2fw chain.That should have read: And decrypted traffic entering on vlan4 would have been passed through the rem2fw chain. Of course, the only decrypted traffic that you expect are the GRE packets. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Wow Tom, I have to say I have not seen a project whose founder and developer is so dedicated to helping users. When I was searching the list I predominately came upon posts from you. I have to say thank you for being persistent and explaining these simple things to me. I think my confusion came from that quote I posted about how entries in tunnels could be easily replaced by rules. I then took upon myself the false impression that I just needed the hole open and Shorewall did not need to know anything about there actually being an ipsec connection. Your post immediately flipped that light on over my head (and made the whole setup work) and if you don''t mind I''d like to use some of it in a blog post, or how-to of some sort. Thanks again for the dedication, this definitely would have turned into a weeklong ordeal like Prasanna warned. Josh -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Friday, January 05, 2007 8:27 AM To: Shorewall Users Subject: Re: [Shorewall-users] GRE over IPSec VPN Joshua Perry wrote:> Well, it wasn''t too difficult, it is running right now, and added masq > from the remote site through this host in just 5 minutes. The problem > I''ve found is the policy match that Shorewall is adding to the > interface''s zone chain rules "policy match dir in pol none" (eg. rule > 2 in vlan4_in) lets ESP through, then blocks the GRE but never gets > stripped to the raw data packets because it is rejected. > > If I add -- like you see below -- the 3rd rule everything works great; > ESP gets in through rule 2 and once in inet2fw there gets accepted by rule3.> GRE then gets pulled from the ESP and gets through vpn4_1 to inet2fw > through rule 3 and accepted by rule 5, then the raw data gets stripped > and shows up in INPUT as IN=vpn1 and sent down the vpn1_in chain and > via rule 2 into evl2fw and accepted there because of evl2fw''s generousrules.> > There is obviously a bit of a dichotomy with how netfilter reacts to > the packets. Basically it deems ESP packets a match to the inbound > policy, not GRE, but the raw packets again are accepted by the policy > match. With just rule 1 & 2 in vlan4_in (default generated by > Shorewall) the setup doesn''t work, but adding by hand with iptables > rule 3 (Or replacing rule 2 with rule > 3) everything works great. > > I''ve made a quick post to the netfilter list to see if maybe it''s a > bug or if that is how it is supposed to work. If it turns out not to > be a bug I need to find a way to make Shorewall not put that policy > match on the zone rules, as well as understand why it is there in thefirst place. Once again, this is not a bug but rather your lack of understanding about what is going on. There are three broad classes of Shorewall zones: a) firewall b) ipv4 c) ipsec The type of zone is specified in the second column of /etc/shorewall/zones. Zones of type ''ipv4'' may have ipsec "groups" included in them. A host group is designated as being ''ipsec'' by including the keyword "ipsec" in the OPTIONS column of /etc/shorewall/hosts. Traffic to/from ipv4 zones is not encrypted by IPSEC. Traffic to/from ipsec zones and/or ipsec host groups is encrypted. Here is what you claim to be your zones file: /etc/shorewall/zones ---------------------------------------------------------------------- fw firewall evl inet local ---------------------------------------------------------------------- You have no ''ipsec'' zones. From looking at the dump that you supplied last night, I see that you have no ipsec host groups. In iptables terms then, your ''inet'' zone is not an ipsec zone so traffic to/from hosts in that zone is not encrypted. That is why this rule is the way that it is: 16 2624 inet2fw all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol none The ''pol none'' says that only traffic from inet hosts that has not been decrypted should pass through that chain. Now if you would have added this to your /etc/shorewall/zones file: rem ipsec and this to your /etc/shorewall/zones file: rem vlan4 - Then you would have seen a rule in the vlan4_in chain such as follows: xx yyyy rem2fw all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec An traffic entering on vlan4 would have been passed through the rem2fw chain. ----------------------------------------------------------------------- Note: Alternatively, you could put this in /etc/shorewallzones: rem ipv4 And this in /etc/shorewall/hosts: rem vlan4:67.42.31.242 ipsec ----------------------------------------------------------------------- Finally, in the /etc/shorewall/tunnels file, you have: /etc/shorewall/tunnels ---------------------------------------------------------------------- gre inet 67.42.31.242 ipsec:noah inet 67.42.31.242 ---------------------------------------------------------------------- The GRE traffic is subject to the IPSEC transport mode SA. So by the time that GRE packets are processed by the Shorewall-generated ruleset, they have been decrypted. As you''ve pointed out, they don''t get sent down the ''inet2fw'' chain but they *would* be sent down the ''rem2fw'' chain. So the first tunnels file entry should be: gre rem 67.42.31.242 That is what I meant about parallel vs. nested tunnels -- the GRE tunnel is nested within the IPSEC transport mode SA and must be defined accordingly. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Joshua Perry wrote:> > Your post immediately flipped that light on over my head (and made the whole > setup work) and if you don''t mind I''d like to use some of it in a blog post, > or how-to of some sort.That would be fine. When you have it set up, let me know and we can add a link from the Shorewall site. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV