Re: [suse-security] ipsec freeswan - connection... packets dropped ... [LONG]

18 Oct 2003

      Hi Markus!

Good news.... think I've accomplished the task. It was really a problem 
with routing (as suggested by Andreas)! This is a really long email.

-= The Solution =-

Seems that I forgot to create static routes on the client machines.
To make things clearer, I'll give an exemple below... after that I'll 
write some things that may be useful to you (sorry if I wrote too much, 
I just prefer not to assume anything about your expertise).

ClientL     G A T E W A Y L               G A T E W A Y R    ClientR
10.1.0.2 -> 10.1.0.1 (eth1)               10.2.0.1 (eth1) <- 10.2.0.2
             aaa.bbb.87.83 (eth0)<=TUNNEL=>xxx.yyy.57.170 (eth0)

Apart from being sure that IP_FORWARD and RP_FILTER are as recommended 
on the configuration docs, the following must also be true :

ClientL... must have a static route to net 10.2.0.0/16 :
              route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.1.0.1
ClientR... must have a static route to net 10.1.0.0/16 :
              route add -net 10.1.0.0 netmask 255.255.0.0 gw 10.2.0.1

GatewayL.. must have FORWARDING rules from/to net 10.2.0.0 on the
            firewall :

            IPTABLES -A FORWARD -s 10.1.0.0/16 -d 10.2.0.0/16 -j ACCEPT
            IPTABLES -A FORWARD -s 10.2.0.0/16 -d 10.1.0.0/16 -j ACCEPT

GatewayR.. must have FORWARDING rules from/to net 10.1.0.0 on the
            firewall :

            IPTABLES -A FORWARD -s 10.2.0.0/16 -d 10.1.0.0/16 -j ACCEPT
            IPTABLES -A FORWARD -s 10.1.0.0/16 -d 10.2.0.0/16 -j ACCEPT

-= How did I came to these conclusions =-

1. Ping from ClientL to GatewayL (eth1).
    This always worked.

2. Ping from ClientL to ClientR
    This never worked.
    So I set the firewall to DROP some packages and LOG them so that I 
could see what was happening.
    This is tricky for SuSE users accostumed to use SuSEfirewall2 
(nothing against). The ¨problem¨ I see with SuSEfirewall2 is that it 
generates A LOT of rules and log registers, which is confusing when I 
was trying to see what was wrong with the VPN. If you feel confortable 
with SuSEfirewall2 then ignore this comment. Insert the usual disclaimer 
here about changing rules on the firewall.

    First clear and open your firewall. Then add the rules to allow 
IPSEC, ESP and AH.Don't forget to add the rules that allow you to access 
the computer using SSH if you're not on the console.

    Now, change the policy of the chains to DROP, so that all that's not 
explicitly allowed will be dropped on the firewall. All these should be 
done on both gateways.

    Zero the iptables counters :
        iptables -Z

    Ping from ClientL to ClientR.

    When I did this, I noticed that no packets were incrementing in any 
chain in the firewall (the DROP counter). You see this with :

        iptables -L -nv

# iptables -L -nv
Chain INPUT (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
   125  9332 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          tcp dpt:22
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          tcp spt:22
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          tcp spt:22
     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0 
0.0.0.0/0          udp spt:500 dpt:500
     0     0 ACCEPT     esp  --  *      *       0.0.0.0/0 
0.0.0.0/0
     0     0 ACCEPT     ah   --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
    68  9872 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          tcp spt:22
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          tcp dpt:22
     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0 
0.0.0.0/0          udp spt:500 dpt:500
     0     0 ACCEPT     esp  --  *      *       0.0.0.0/0 
0.0.0.0/0
     0     0 ACCEPT     ah   --  *      *       0.0.0.0/0 
0.0.0.0/0

    So I could be sure that the ping from ClientL to ClientR was NEVER 
reaching my gateway. That's when I fixed the routing tables on the 
client machines.

    Next, the firewall was DROPPING packets accordingly with the PING 
command.

    IPTABLES differs from IPCHAINS in that the first only uses the INPUT 
and OUTPUT chains for packets TO and FROM the firewall. If a packet will 
go from one interface (eth1) to another (eth0 or ipsec0), then the 
packet goes directly to the FORWARD chain.In IPCHAINS, a packet would 
traverse all chains.

    If you want to PING the local interface on the gateway you must 
allow ICMP packet on the INPUT chain. If you want to PING from the 
gateway, you must allow ICMP packets on the OUTPUT chain :

            IPTABLES -A INPUT -p icmp -j ACCEPT
            IPTABLES -A OUTPUT -p icmp -j ACCEPT

    So, I was seeing on the counters of the ¨iptables -L -nv¨ that the 
packets were dropped on the FORWARD chain. That's when I added the rules 
to forward the packets from one net to the other :

            IPTABLES -A FORWARD -s 10.1.0.0/16 -d 10.2.0.0/16 -j ACCEPT
            IPTABLES -A FORWARD -s 10.2.0.0/16 -d 10.1.0.0/16 -j ACCEPT

     After doing that on both gateways I could ping from one client to 
the other. Ping, ssh, nmap... all worked fine.

     Hope I didn't forget anything!

-= What's next =-

     Road Warrior
     X509
     Autenticating on a Windows Domain from Win2000, Win98, WinXP clients.

Feel free to comment, blame, or ask anything else.

Thanks to all!
EdK

Markus Feilner wrote:
...
Am Freitag, 17. Oktober 2003 15:34 schrieb Elite Mentor:
...
Hi Markus, Andreas, et all...
I´m gonna do a major re-check on routing... for the n-th time.
My /proc/sys/net/ipv4 files are ok ... ip_forward=1 and
rp_filter=0.
In some doc I read that this communication has to work before I start
ipsec... but that could only happen if I mask the packets. Should I
try this before bringing up the ipsec?
About freeswan lists... I read a lot of emails at the archive but
many of them with similar problems are unanswered... I just didn´t
feel like posting one more there.
that's right, I even PMed to some of the folks there, but I'm still 
waiting...
let's see, we'll get this thing workng, won't we?
!!!
...
Thank you people!
EdK
...
Markus Feilner  wrote:
Am Freitag, 17. Oktober 2003 08:28 schrieb Andreas Baetz:
...
Ed,
You could check the following:
Is the routing between the subnets correct ?
Do the packets arrive at the eth-Interface of your source GW ?
Is forwarding switched on at the GW ?
Andreas
(...)
A) I'm not quite sure if routing is correct, but ipsec works one-way
(if it's initiated from one side, so i think routing shoud be ok.)
forwarding is switched on.
here's an extract from tcpdump -i ipsec0 (on the right-hand-Server)
----------------
14:09:34.824650 217.229.160.84 > 192.168.89.12: icmp: echo request
(DF) 14:09:34.852147 192.168.89.12 > 192.168.0.4: icmp: echo request
14:09:34.852393 192.168.0.4 > 192.168.89.12: icmp: echo reply
14:09:35.824675 217.229.160.84 > 192.168.89.12: icmp: echo request
(DF) 14:09:35.846827 192.168.89.12 > 192.168.0.4: icmp: echo request
14:09:35.847018 192.168.0.4 > 192.168.89.12: icmp: echo reply
14:09:36.824670 217.229.160.84 > 192.168.89.12: icmp: echo request
(DF) 14:09:36.847427 192.168.89.12 > 192.168.0.4: icmp: echo request
14:09:36.847605 192.168.0.4 > 192.168.89.12: icmp: echo reply
14:09:37.824697 217.229.160.84 > 192.168.89.12: icmp: echo request
(DF) 14:09:37.851494 192.168.89.12 > 192.168.0.4: icmp: echo request
14:09:37.851698 192.168.0.4 > 192.168.89.12: icmp: echo reply
-------------------
As you can see, i managed to have leftside hosts ping to the right
side and get answers (ssh works, too). But the other way round,
packets are dropped. 217.229.160.84 is my current IP on the right
side - is this right? Shouldn't the local IP of the pinging host
stand here?
route says:
-----------------right server--------------
Server:/ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
a.b.c.d * 255.255.255.255 UH 0 0 0
ppp0
a.b.c.d * 255.255.255.255 UH 0 0 0
ipsec0
10.0.0.0 * 255.255.255.0 U 0 0 0
eth0
192.168.0.0 * 255.255.255.0 U 0 0 0
eth1
192.168.89.0 * 255.255.255.0 U 0 0 0
ipsec0
default a.b.c.d 0.0.0.0 UG 0 0 0
ppp0
Server:/ #
(a.b.c.d is the p-t-p partner of my dsl conn)
------------------------------------------------
----------------left server--------------------
Server1:/ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
e.f.g.h 0.0.0.0 255.255.255.240 U 0 0 0 eth1
e.f.g.h 0.0.0.0 255.255.255.240 U 0 0 0 ipsec0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
ipsec0
192.168.89.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 e.f.g.i 0.0.0.0 UG 0 0 0 eth1
Server1:/ #
with e.f.g.h the local (fixed) IP of the Subnet and e.f.g.i the IP of
Server1.
----------------------------------------------------
and eroute says:
-------------right-side------------------
Server:/ # ipsec eroute
4 192.168.0.0/24:0 -> 192.168.89.0/24:0 =>
tun0x1002@e.f.g.i:0
Server:/ #
-------------left-side--------------------
Server1:/ # ipsec eroute
4 192.168.89.0/24:0 -> 192.168.0.0/24:0 =>
tun0x1004@217.229.160.84:0
Server1:/ #
-------------------------------------------
Howerver, pings from a host in subnet 192.168.0.0 (=right) to the
left are dropped on interface ipsec0. But not if the connection has
been established from left-hand-side.
----------------------------dropped packets---------------
Server:/ # ifconfig ipsec0
ipsec0 Link encap:IPIP Tunnel HWaddr
inet addr:217.229.160.84 Mask:255.255.255.255
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:612 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:240 (240.0 b) TX bytes:448 (448.0 b)
Server:/ #
--------------------------------------------------------------
As you can see, four pakets came from left-side and were answered,
but the 612 pings from right to left were dropped.
Strange.
I'll take a deep look into my Firewall rules, but there should be no
such rule preventing that.
Are there any kernel runtime parameters concerning this?
I have all rp_filter = 0, ip_forward=1 - and what do i need more?
Any help is welcome!

Re: [suse-security] ipsec freeswan - connection... packets dropped ... [LONG]

Techno Ed