[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 <lists@xxxxxxxxxxxxxx> 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@xxxxxxx:0
Server:/ #
-------------left-side--------------------

Server1:/ # ipsec eroute
4 192.168.89.0/24:0 -> 192.168.0.0/24:0 =>
tun0x1004@xxxxxxxxxxxxxx: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!




--
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