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 On Friday 17 October 2003 07:02, Techno Ed wrote:

Hi Markus.

I'm with a similar problem as you with a few (big?) differences.

I'm trying a net-to-net connection (could it be simpler?) :

GW1 is a SuSE Pro 8.2 with FreeS/WAN 1.99_0.9.23-20 GW2 is a RedHat 9.0 with FreeS/WAN 1.99_2.4.20_8-0

-= Starting IPSEC on GW1 =-

/etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.99... ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1 ipsec_setup: klipsdebug=`all' ignored, KLIPS lacks debug facilities ipsec_setup: done

-= Starting IPSEC on GW2 =-

# /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.99... ipsec_setup: Using /lib/modules/2.4.20-8/kernel/net/ipsec/ipsec.o

-= Activating the connection on GW1 =-

# ipsec auto --up net-to-net 104 "net-to-net" #1: STATE_MAIN_I1: initiate 106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established 112 "net-to-net" #2: STATE_QUICK_I1: initiate 010 "net-to-net" #2: STATE_QUICK_I1: retransmission; will wait 20s for response 004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

-= Checking tunnel =-

... on GW1 # ipsec eroute 0 10.21.0.0/16:0 -> 10.31.0.0/16:0 => tun0x1002@aaa.bbb.57.170:0

... Second line after 'ipsec look' begins weird for me... shouldn't it be 10.31.0.0/16 ? Maybe it's just a different format...

# ipsec look GW1 Fri Oct 17 02:32:37 UTC 2003 001003100000016:0:10.21.0.0/16:0 -> 10.31.0.0/16:0 => tun0x1002@aaa.bbb.57.170:0 (0) ipsec0->NULL mtu=16260(0)->0 esp0x532de87c@xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=in src=aaa.bbb.57.170 iv_bits=64bits iv=0xf7bb2971e2981f85 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0) esp0x935e8ab8@aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=out src=xxx.yyy.87.83 iv_bits=64bits iv=0xa8a51aa30756b8ab ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0) tun0x1001@xxx.yyy.87.83 IPIP: dir=in src=aaa.bbb.57.170 life(c,s,h)=addtime(175,0,0) tun0x1002@aaa.bbb.57.170 IPIP: dir=out src=xxx.yyy.87.83 life(c,s,h)=addtime(175,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 xxx.yyy.87.81 0.0.0.0 UG 0 0 0 eth0 xxx.yyy.87.80 0.0.0.0 255.255.255.240 U 0 0 0 eth0

... on GW2 (just to be sure) ]# ipsec eroute 0 10.31.0.0/16 -> 10.21.0.0/16 => tun0x1002@xxx.yyy.87.83

# ipsec look GW2 Fri Oct 17 02:27:27 UTC 2003 10.31.0.0/16 -> 10.21.0.0/16 => tun0x1002@xxx.yyy.87.83 esp0x532de87c@xxx.yyy.87.83 (0) ipsec0->eth0 mtu=16260(1500)->1500 esp0x532de87c@xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=out src=aaa.bbb.57.170 iv_bits=64bits iv=0x002d8b0a1a65f3f8 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(426,0,0) esp0x935e8ab8@aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=in src=xxx.yyy.87.83 iv_bits=64bits iv=0xde7993e484323ee7 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(437,0,0) tun0x1001@aaa.bbb.57.170 IPIP: dir=in src=xxx.yyy.87.83 life(c,s,h)=addtime(436,0,0) tun0x1002@xxx.yyy.87.83 IPIP: dir=out src=aaa.bbb.57.170 life(c,s,h)=addtime(426,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 aaa.bbb.57.190 0.0.0.0 UG 0 0 0 eth0 10.21.0.0 aaa.bbb.57.190 255.255.0.0 UG 0 0 0 ipsec0 aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0 aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0 ipsec0

-= Conf file =-

# cat /etc/ipsec.conf

config setup interfaces=%defaultroute klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=yes

conn net-to-net keyingtries=0 authby=rsasig left=xxx.yyy.87.83 leftsubnet=10.21.0.0/16 leftid=GW1.domain.com leftrsasigkey=SUFpqti6..... leftnexthop=%defaultroute right=aaa.bbb.57.170 rightsubnet=10.31.0.0/16 rightid=GW2.domain.com.br rightrsasigkey=YrGqXcM..... rightnexthop=%defaultroute auto=add

-= Firewall Rules =-

Quite the same in both GW's.

#!/bin/bash

IPT=/usr/sbin/iptables

$IPT -t nat -F $IPT -t filter -F $IPT -t mangle -F

$IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT $IPT -P FORWARD ACCEPT

$IPT -A INPUT -i eth0 -p icmp -j ACCEPT $IPT -A INPUT -i eth1 -p icmp -j ACCEPT $IPT -A INPUT -i ipsec+ -p icmp -j ACCEPT $IPT -A OUTPUT -p icmp -j ACCEPT

$IPT -A FORWARD -s 10.21.0.0/16 -d 10.31.0.0/16 -j ACCEPT $IPT -A FORWARD -s 10.31.0.0/16 -d 10.21.0.0/16 -j ACCEPT

$IPT -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT $IPT -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT

$IPT -A INPUT -p 50 -j ACCEPT $IPT -A OUTPUT -p 50 -j ACCEPT

$IPT -A INPUT -p 51 -j ACCEPT $IPT -A OUTPUT -p 51 -j ACCEPT

$IPT -A INPUT -j LOG --log-prefix "INPUT --- " $IPT -A OUTPUT -j LOG --log-prefix "OUTPUT --- " $IPT -A FORWARD -j LOG --log-prefix "FORWARD --- "

$IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

-= The problem =-

Can't PING, for example, from GW1 : ping -I eth1 10.31.100.2

Can't ping from 10.31.100.2 to 10.21.100.30

Workstations on the same subnet as the GW ping as expected.

No drops on the firewall... in fact, there is no traffic in the FORWARD chain... which seems strange. Tried TCPDUMPing but captured nothing on ipsec0.

Am I missing WHAT (besides the packets) ? I'm already feeling dizzy and kinda frustrated with this... after all, everywhere I read, they say this is the simpler VPN connection.

Thanks!

EdK

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

Well, for my part, the routing is correct, at least partly: ackets from x.x.0.0 (which is the local subnet) to the tunneled subnet x.x.89.0 are routed to interface ipsec0, how a tcpdump shows (see last mail) ed, have you done a tcpdump -i ipsec0 on either side, while doing a ping from left a subnet host to the right subnet host? Please do and mail the outcome... I#m sure together we'll manage this. thanx! BTW, I posted this also on freeswan-users, but i did not get any replys (so far), CU!

On Friday 17 October 2003 07:02, Techno Ed wrote:

...

Hi Markus.

I'm with a similar problem as you with a few (big?) differences.

I'm trying a net-to-net connection (could it be simpler?) :

GW1 is a SuSE Pro 8.2 with FreeS/WAN 1.99_0.9.23-20 GW2 is a RedHat 9.0 with FreeS/WAN 1.99_2.4.20_8-0

-= Starting IPSEC on GW1 =-

/etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.99... ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1 ipsec_setup: klipsdebug=`all' ignored, KLIPS lacks debug facilities ipsec_setup: done

-= Starting IPSEC on GW2 =-

# /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.99... ipsec_setup: Using /lib/modules/2.4.20-8/kernel/net/ipsec/ipsec.o

-= Activating the connection on GW1 =-

# ipsec auto --up net-to-net 104 "net-to-net" #1: STATE_MAIN_I1: initiate 106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established 112 "net-to-net" #2: STATE_QUICK_I1: initiate 010 "net-to-net" #2: STATE_QUICK_I1: retransmission; will wait 20s for response 004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

-= Checking tunnel =-

... on GW1 # ipsec eroute 0 10.21.0.0/16:0 -> 10.31.0.0/16:0 => tun0x1002@aaa.bbb.57.170:0

... Second line after 'ipsec look' begins weird for me... shouldn't it be 10.31.0.0/16 ? Maybe it's just a different format...

# ipsec look GW1 Fri Oct 17 02:32:37 UTC 2003 001003100000016:0:10.21.0.0/16:0 -> 10.31.0.0/16:0 => tun0x1002@aaa.bbb.57.170:0 (0) ipsec0->NULL mtu=16260(0)->0 esp0x532de87c@xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=in src=aaa.bbb.57.170 iv_bits=64bits iv=0xf7bb2971e2981f85 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0) esp0x935e8ab8@aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=out src=xxx.yyy.87.83 iv_bits=64bits iv=0xa8a51aa30756b8ab ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0) tun0x1001@xxx.yyy.87.83 IPIP: dir=in src=aaa.bbb.57.170 life(c,s,h)=addtime(175,0,0) tun0x1002@aaa.bbb.57.170 IPIP: dir=out src=xxx.yyy.87.83 life(c,s,h)=addtime(175,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 xxx.yyy.87.81 0.0.0.0 UG 0 0 0 eth0 xxx.yyy.87.80 0.0.0.0 255.255.255.240 U 0 0 0 eth0

... on GW2 (just to be sure) ]# ipsec eroute 0 10.31.0.0/16 -> 10.21.0.0/16 => tun0x1002@xxx.yyy.87.83

# ipsec look GW2 Fri Oct 17 02:27:27 UTC 2003 10.31.0.0/16 -> 10.21.0.0/16 => tun0x1002@xxx.yyy.87.83 esp0x532de87c@xxx.yyy.87.83 (0) ipsec0->eth0 mtu=16260(1500)->1500 esp0x532de87c@xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=out src=aaa.bbb.57.170 iv_bits=64bits iv=0x002d8b0a1a65f3f8 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(426,0,0) esp0x935e8ab8@aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=in src=xxx.yyy.87.83 iv_bits=64bits iv=0xde7993e484323ee7 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(437,0,0) tun0x1001@aaa.bbb.57.170 IPIP: dir=in src=xxx.yyy.87.83 life(c,s,h)=addtime(436,0,0) tun0x1002@xxx.yyy.87.83 IPIP: dir=out src=aaa.bbb.57.170 life(c,s,h)=addtime(426,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 aaa.bbb.57.190 0.0.0.0 UG 0 0 0 eth0 10.21.0.0 aaa.bbb.57.190 255.255.0.0 UG 0 0 0 ipsec0 aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0 aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0 ipsec0

-= Conf file =-

# cat /etc/ipsec.conf

config setup interfaces=%defaultroute klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=yes

conn net-to-net keyingtries=0 authby=rsasig left=xxx.yyy.87.83 leftsubnet=10.21.0.0/16 leftid=GW1.domain.com leftrsasigkey=SUFpqti6..... leftnexthop=%defaultroute right=aaa.bbb.57.170 rightsubnet=10.31.0.0/16 rightid=GW2.domain.com.br rightrsasigkey=YrGqXcM..... rightnexthop=%defaultroute auto=add

-= Firewall Rules =-

Quite the same in both GW's.

#!/bin/bash

IPT=/usr/sbin/iptables

$IPT -t nat -F $IPT -t filter -F $IPT -t mangle -F

$IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT $IPT -P FORWARD ACCEPT

$IPT -A INPUT -i eth0 -p icmp -j ACCEPT $IPT -A INPUT -i eth1 -p icmp -j ACCEPT $IPT -A INPUT -i ipsec+ -p icmp -j ACCEPT $IPT -A OUTPUT -p icmp -j ACCEPT

$IPT -A FORWARD -s 10.21.0.0/16 -d 10.31.0.0/16 -j ACCEPT $IPT -A FORWARD -s 10.31.0.0/16 -d 10.21.0.0/16 -j ACCEPT

$IPT -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT $IPT -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT

$IPT -A INPUT -p 50 -j ACCEPT $IPT -A OUTPUT -p 50 -j ACCEPT

$IPT -A INPUT -p 51 -j ACCEPT $IPT -A OUTPUT -p 51 -j ACCEPT

$IPT -A INPUT -j LOG --log-prefix "INPUT --- " $IPT -A OUTPUT -j LOG --log-prefix "OUTPUT --- " $IPT -A FORWARD -j LOG --log-prefix "FORWARD --- "

$IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

-= The problem =-

Can't PING, for example, from GW1 : ping -I eth1 10.31.100.2

Can't ping from 10.31.100.2 to 10.21.100.30

Workstations on the same subnet as the GW ping as expected.

No drops on the firewall... in fact, there is no traffic in the FORWARD chain... which seems strange. Tried TCPDUMPing but captured nothing on ipsec0.

Am I missing WHAT (besides the packets) ? I'm already feeling dizzy and kinda frustrated with this... after all, everywhere I read, they say this is the simpler VPN connection.

Thanks!

EdK

-- Mit freundlichen Grüßen Markus Feilner -- Linux Solutions, Training, Seminare und Workshops - auch Inhouse Feilner IT Linux & GIS Erlangerstr. 2 93059 Regensburg fon: +49 941 70 65 23 - mobil: +49 170 302 709 2 web: http://feilner-it.net mail: mfeilner@feilner-it.net

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. 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! -- Mit freundlichen Grüßen Markus Feilner -- Linux Solutions, Training, Seminare und Workshops - auch Inhouse Feilner IT Linux & GIS Erlangerstr. 2 93059 Regensburg fon: +49 941 70 65 23 - mobil: +49 170 302 709 2 web: http://feilner-it.net mail: mfeilner@feilner-it.net -- 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 --------------------------------- Yahoo! Mail - o melhor webmail do Brasil. Saiba mais!

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!

On Saturday 18 October 2003 12:28, Markus Feilner wrote:

Am Freitag, 17. Oktober 2003 12:18 schrieb Frank Stuehmer:

...

Hi Markus,

...

I stopped all Firewall rules, and checked the ipsec configuration over and over, but i can't find a solution. Can anyone help me?

do you have in /etc/ipsec.conf lines like this: leftupdown=/usr/lib/ipsec/_updown.x509 ? In _updown.x509 routing and firewalling for ipsec connection will be set. With Suse-Firewall this configuration works fine for me.

Frank Stuehmer

Yes, I do. But that's not enough. And I tried with or without the gw entry in line 55 - as described on https://nso.freeswan.nl/archives/users/2003-September/msg00227.html this proved to be necessary for the routing. Now ping left-net-host -> right-net-host works, but ping right-net-host -> left-net-host doesn't. Packets are dropped on left-net-VPN-Server's interface ipsec0. but why? It answers correctly on a connection initiated from left-side-host, but can not ping to the other side... ???? So your packets go from right-net-host over right-net-gw through the tunnel to left-net-gw, there they are dropped ? Are they dropped by a firewall rule ?

Andreas