-- Kind regards i.A. Carsten Voigt bios ag (hrb-hh 73193) brauhausstieg 15-17 d-22041 hamburg fon +49 40 689 439 0 fax +49 40 689 439 39 cvo@bios.de www.bios.de aufsichtsratsvorsitzender: wolfgang borchert vorstand: ulrich kalthoff, heinrich zwiebelmann -------- Original-Nachricht -------- Betreff: Re: [suse-security] VPN and SuSEfirewall2 Datum: Thu, 27 Apr 2006 18:28:57 +0930 Von: Jonathan Baxter jbaxter@panscient.com An: suse-security@suse.com Referenzen: 200604271536.13792.jbaxter@panscient.com 20060427071254.GA16610@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 -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here