Mailinglist Archive: opensuse-security (88 mails)

< Previous Next >
[Fwd: Re: [suse-security] VPN and SuSEfirewall2]
  • From: Carsten Voigt <cvo@xxxxxxx>
  • Date: Thu, 27 Apr 2006 11:24:02 +0200
  • Message-id: <44508DB2.20204@xxxxxxx>

Jonathan,

if you ping one interface of a host you can surely reach by another, you might get an answer, even if the host adressed even does not forward anything.
You just do really know routers are routing, if something behind router A is reaching something behind router B.

--
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@xxxxxxx
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@xxxxxxxxxxxxx>
An: suse-security@xxxxxxxx
Referenzen: <200604271536.13792.jbaxter@xxxxxxxxxxxxx> <20060427071254.GA16610@xxxxxxx>



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@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here






< Previous Next >
Follow Ups