VPN and SuSEfirewall2
Please excuse me if this is not the correct forum for VPN and firewall issues on SuSE. I am trying to setup an ipsec VPN between two private subnets, and I have run into a snag that I cannot resolve. The VPN establishes itself fine, and I can connect from any machine on the right subnet to any machine on the left subnet, but not vice versa. Here's the setup: 192.168.1.0/24===a.a.a.a---b.b.b.b...c.c.c.c---d.d.d.d===192.168.200.0/24 "a.a.a.a" is the external interface of a SuSE 10.0 box which masquerades machines on the internal 192.168.1.0/24 subnet. "b.b.b.b" is its nexthop router. "d.d.d.d" is the external interface of my home linksys AG241 DSL router. "c.c.c.c" is its nexthop router (at the ISP). I have an ipsec, pre-shared key tunnel from a.a.a.a to d.d.d.d. The SuSE box is running it with OpenSwan, the linksys router is just set up via the normal linksys configuration (which may well be OpenSwan under the hood). Everything works fine from right-to-left - ie all machines on the 192.168.200.0 subnet behind the linksys router can see all machines on the 192.168.1.0 subnet behind the SuSE box. But nothing works from left-to right; neither the SuSE router box itself, nor from any machines on the 192.168.1.0 subnet behind it can see any machines on the 192.168.200.0 subnet at the other end of the tunnel. This seems to me like it must be a routing problem, but I can't for the life of me work out how to fix it. I am running SuSEfirewall2 on the SuSE router. I have explicitly enabled forwarding between the two subnets by setting FW_FORWARD in /etc/sysconfig/SuSEfirewall2: FW_FORWARD="192.168.1.0/24,192.168.200.0/24,,,ipsec \ 192.168.200.0/24,192.168.1.0/24,,,ipsec" I have explicitly disabled NAT of packets between the two subnets by adding the following line to the fw_custom_before_port_handling() section of /etc/sysconfig/scripts/SuSEfirewall2-custom: iptables -t nat -A POSTROUTING -o eth2 -s 192.168.1.0/24 -d \! 192.168.200.0/24 -j MASQUERADE the tunnel config in /etc/ipsec.conf looks like: conn net-to-net # Key exchange method authby=secret # Left security gateway, subnet behind it, nexthop toward right. left=a.a.a.a leftsubnet=192.168.1.0/24 leftnexthop=b.b.b.b # Right security gateway, subnet behind it, nexthop toward left. right=d.d.d.d rightsubnet=192.168.200.0/24 rightnexthop=c.c.c.c auto=start Any suggestions? Thanks, Jonathan Baxter
Jonathan Baxter wrote:
[...] But nothing works from left-to right; neither the SuSE router box itself, nor
The router itself cannot reach the subnet on the other side if you use it's external IP as source. You'd need a second tunnel for that.
from any machines on the 192.168.1.0 subnet behind it can see any machines on the 192.168.200.0 subnet at the other end of the tunnel. [...] I am running SuSEfirewall2 on the SuSE router. I have explicitly enabled forwarding between the two subnets by setting FW_FORWARD in /etc/sysconfig/SuSEfirewall2:
FW_FORWARD="192.168.1.0/24,192.168.200.0/24,,,ipsec \ 192.168.200.0/24,192.168.1.0/24,,,ipsec"
Looks correct.
I have explicitly disabled NAT of packets between the two subnets by adding the following line to the fw_custom_before_port_handling() section of /etc/sysconfig/scripts/SuSEfirewall2-custom:
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.1.0/24 -d \! 192.168.200.0/24 -j MASQUERADE
Packets to 192.168.200.0/24 do not match that rule and fall through to the rule SuSEfirewall2 creates I guess. Try FW_MASQ_NETS="0/0,!192.168.200.0/24" cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
On Thursday 27 April 2006 16:42, Ludwig Nussel wrote:
Jonathan Baxter wrote:
[...] But nothing works from left-to right; neither the SuSE router box itself, nor
The router itself cannot reach the subnet on the other side if you use it's external IP as source. You'd need a second tunnel for that.
I think I understand what you're getting at. If the external IP address is the source address the packets won't get redirected down the tunnel, because the tunnel's source is the internal network. Reproducing the network diagram: 192.168.1.0/24===a.a.a.a---b.b.b.b...c.c.c.c---d.d.d.d===192.168.200.0/24 "a.a.a.a" is the external interface of the problematic SuSE box, 192.168.1.1 is its internal interface. d.d.d.d is the external interface of the linksys router, 192.168.200.1 is the internal interface. With tcpdump on the SuSE router, I see the following when pinging from right to left (192.168.200.2 -> 192.168.1.2): IP 192.168.200.2 > 192.168.1.2: ICMP echo request, id 51223, seq 18, length 64 IP 192.168.200.2 > 192.168.1.2: ICMP echo request, id 51223, seq 18, length 64 IP a.a.a.a > b.b.b.b: ESP(spi=xxx,seq=0x15), length 116 So that works fine (I don't know why there are two decoded lines per ping, but at least it seems correct: ESP packet between the external addresses decoded to the ICMP packet between the internal addresses). However, if I ping the other way (192.168.1.2 -> 192.168.200.2), tcpdump on the SuSE router shows: IP a.a.a.a > 192.168.200.2: ICMP echo request, id 25444, seq 18, length 64 No "ESP" packet. Since the source address is rewritten as "a.a.a.a", does that means the packets from 192.168.1.2 are being masqueraded, which per Ludwig's comment above means they are not being directed down the tunnel? If so, I guess my iptables directive in /etc/sysconfig/scripts/SuSEfirewall2-custom is not working:
I have explicitly disabled NAT of packets between the two subnets by adding the following line to the fw_custom_before_port_handling() section of /etc/sysconfig/scripts/SuSEfirewall2-custom:
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.1.0/24 -d \! 192.168.200.0/24 -j MASQUERADE
But if I do as Ludwig suggests and set FW_MASQ_NETS="0/0,!192.168.200.0/24" in /etc/sysconfig/SuSEfirewall2 then the firewall drops the packets from 192.168.1.2 altogether - they never make it to the external interface on the SuSE router at all. I get the following in /var/log/firewall: SFW2-FWDint-DROP-DEFLT IN=eth1 OUT=eth2 SRC=192.168.1.2 DST=192.168.200.2 So I guess the left->right packets are not making it down the tunnel, but I am still confused as to why not..... - Jonathan
Jonathan Baxter wrote:
On Thursday 27 April 2006 16:42, Ludwig Nussel wrote:
Jonathan Baxter wrote:
[...] But nothing works from left-to right; neither the SuSE router box itself, nor
The router itself cannot reach the subnet on the other side if you use it's external IP as source. You'd need a second tunnel for that.
I think I understand what you're getting at. If the external IP address is the source address the packets won't get redirected down the tunnel, because the tunnel's source is the internal network.
Exactly.
[...]
I have explicitly disabled NAT of packets between the two subnets by adding the following line to the fw_custom_before_port_handling() section of /etc/sysconfig/scripts/SuSEfirewall2-custom:
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.1.0/24 -d \! 192.168.200.0/24 -j MASQUERADE
But if I do as Ludwig suggests and set FW_MASQ_NETS="0/0,!192.168.200.0/24" in /etc/sysconfig/SuSEfirewall2 then the firewall drops the packets from 192.168.1.2 altogether - they never make it to the external interface on the SuSE router at all. I get the following in /var/log/firewall:
SFW2-FWDint-DROP-DEFLT IN=eth1 OUT=eth2 SRC=192.168.1.2 DST=192.168.200.2
So I guess the left->right packets are not making it down the tunnel, but I am still confused as to why not.....
Me too. I wouldn't be surprised if it is a bug in SuSEfirewall2. You are probably the first person that actually uses those features in a real world setup :-) Please send me your /etc/sysconfig/SuSEfirewall2 and the output of "SuSEfirewall2 status". cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
On Thu, 27 Apr 2006, Ludwig Nussel wrote:
Jonathan Baxter wrote:
On Thursday 27 April 2006 16:42, Ludwig Nussel wrote:
Jonathan Baxter wrote:
[...] But nothing works from left-to right; neither the SuSE router box itself, nor
The router itself cannot reach the subnet on the other side if you use it's external IP as source. You'd need a second tunnel for that.
I think I understand what you're getting at. If the external IP address is the source address the packets won't get redirected down the tunnel, because the tunnel's source is the internal network.
Exactly.
[...]
I have explicitly disabled NAT of packets between the two subnets by adding the following line to the fw_custom_before_port_handling() section of /etc/sysconfig/scripts/SuSEfirewall2-custom:
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.1.0/24 -d \! 192.168.200.0/24 -j MASQUERADE
But if I do as Ludwig suggests and set FW_MASQ_NETS="0/0,!192.168.200.0/24" in /etc/sysconfig/SuSEfirewall2 then the firewall drops the packets from 192.168.1.2 altogether - they never make it to the external interface on the SuSE router at all. I get the following in /var/log/firewall:
SFW2-FWDint-DROP-DEFLT IN=eth1 OUT=eth2 SRC=192.168.1.2 DST=192.168.200.2
So I guess the left->right packets are not making it down the tunnel, but I am still confused as to why not.....
Me too. I wouldn't be surprised if it is a bug in SuSEfirewall2. You are probably the first person that actually uses those features in a real world setup :-)
we have firewalls with slackbased bootcd and use SFW2 and ipsec vpn running for more than a year now :: FW_MASQ_DEV="eth1" FW_MASQ_NETS="192.168.1.0/24 192.168.2.0/24" no FW_FORWARD_ thing but simple route entries. cheers -- --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
Hallelujah. It works. I changed: FW_FORWARD="192.168.1.0/24,192.168.200.0/24,,,ipsec \ 192.168.200.0/24,192.168.1.0/24,,,ipsec" to: FW_FORWARD="192.168.1.0/24,192.168.200.0/24 \ 192.168.200.0/24,192.168.1.0/24" ie, dropped the "ipsec" flag. The documentation in SuSEfirewall2 seems to imply that the ipsec flag should be there, so maybe this is a bug: # Examples: # - "192.168.1.0/24,10.10.0.0/16,,,ipsec \ # 10.10.0.0/16,192.168.1.0/24,,,ipsec" permit traffic # from 192.168.1.0/24 to 10.10.0.0/16 and vice versa # provided that both networks are connected via an # IPsec tunnel. It may be worth adding a remark to /usr/share/doc/packages/openswan/README.SUSE listing the parameters that need to be configured in SuSEfirewall2 for network-network ipsec to work (assuming you want to use both ipsec VPN and the SuSE firewall together. Personally I like the SuSE firewall configuration, which is why I wasted so much time on this....). Thanks to everyone who replied. - Jonathan
Jonathan Baxter wrote:
Hallelujah. It works.
I changed:
FW_FORWARD="192.168.1.0/24,192.168.200.0/24,,,ipsec \ 192.168.200.0/24,192.168.1.0/24,,,ipsec"
to:
FW_FORWARD="192.168.1.0/24,192.168.200.0/24 \ 192.168.200.0/24,192.168.1.0/24"
ie, dropped the "ipsec" flag.
The documentation in SuSEfirewall2 seems to imply that the ipsec flag should be there, so maybe this is a bug:
No it's a feature :-) The flag prevents network traffic from leaking to the outside network in case the tunnel goes down. Does it work with ipsec flag if you change IPSEC_MATCH="-m policy --dir in --pol ipsec --proto esp" to IPSEC_MATCH="-m policy --pol ipsec --proto esp" in /sbin/SuSEfirewall2? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
Does it work with ipsec flag if you change
IPSEC_MATCH="-m policy --dir in --pol ipsec --proto esp"
to
IPSEC_MATCH="-m policy --pol ipsec --proto esp"
in /sbin/SuSEfirewall2?
/sbin/Susefirewall2 barfs with that change: SuSEfirewall2: batch committing... iptables-batch v1.3.3: policy match: neither --in nor --out specified Try `iptables-batch -h' or 'iptables-batch --help' for more information. Looks like you have to specify a direction. So I added two new variables to /sbin/SuSEfirewall2: IPSEC_INPUT_MATCH="-m policy --dir in --pol ipsec --proto esp" IPSEC_OUTPUT_MATCH="-m policy --dir out --pol ipsec --proto esp" and then used IPSEC_INPUT_MATCH in place of IPSEC_MATCH for the input chain, and added IPSEC_OUTPUT_MATCH to the forward chain. So the "allow_ipsec()" function becomes: allow_ipsec() { if [ -n "$ipsec_chain" ]; then $IPTABLES -A INPUT -j "input_$ipsec_chain" $IPSEC_INPUT_MATCH $IPTABLES -A FORWARD -j "forward_$ipsec_chain" $IPSEC_INPUT_MATCH $IPTABLES -A FORWARD -j "forward_$ipsec_chain" $IPSEC_OUTPUT_MATCH fi } and the forwarding_rules() function becomes: forwarding_rules() { local nets net1 net2 flags more_args_in more_args_out chain for nets in $FW_FORWARD; do IFS=, eval set -- \$nets net1="$1" net2="$2" proto="$3" port="$4" flags="$5" rport="" more_args_in= more_args_out= case "$flags" in "") ;; ipsec) more_args_in="$IPSEC_INPUT_MATCH" more_args_out="$IPSEC_OUTPUT_MATCH" ;; *) echo "Error: unsupported flag in FW_FORWARD: $flags" net1="" ;; esac if [ -n "$proto" ] && ! check_proto_port "$proto" "$port" '' "FW_FORWARD"; then continue fi if [ -n "$net1" -a -n "$net2" ]; then for chain in $forward_zones; do chain=forward_$chain $LAC $IPTABLES -A $chain -j LOG ${LOG}"-`rulelog $chain`-ACC-FORW " -s $net1 -d $net2 $proto $port -m state --state NEW $more_args_in $LAC $IPTABLES -A $chain -j LOG ${LOG}"-`rulelog $chain`-ACC-FORW " -s $net1 -d $net2 $proto $port -m state --state NEW $more_args_out $LAA $IPTABLES -A $chain -j LOG ${LOG}"-`rulelog $chain`-ACC-FORW " -s $net1 -d $net2 $proto $port $more_args_in $LAA $IPTABLES -A $chain -j LOG ${LOG}"-`rulelog $chain`-ACC-FORW " -s $net1 -d $net2 $proto $port $more_args_out $IPTABLES -A $chain -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $net1 -d $net2 $proto $port $more_args_in $IPTABLES -A $chain -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $net1 -d $net2 $proto $port $more_args_out $IPTABLES -A $chain -j "$ACCEPT" -m state --state ESTABLISHED,RELATED -s $net2 -d $net1 $proto $rport $more_args_in $IPTABLES -A $chain -j "$ACCEPT" -m state --state ESTABLISHED,RELATED -s $net2 -d $net1 $proto $rport $more_args_out done else error "too few parameters in FW_FORWARD -> $nets" fi done } (there's almost certainly a better way to do this, but this was the quickest way for me to hack /sbin/SuSEfirewall2 as-is). Anyway, with those changes the router/firewall box will forward through the tunnel in both directions, with the ipsec flag set in FW_FORWARD. Thanks again for all your help. I can send you my ugly hacked SuSEfirewall2 script if you want it :) Cheers, Jonathan
participants (3)
-
engelbert.gruber＠ssg.co.at -
Jonathan Baxter -
Ludwig Nussel