* Stefan_Walther@gehag-dsk.de wrote on Wed, Aug 29, 2001 at 07:32 +0200:

I'm using SuSE7.1 and FreeS/WAN 1.91. The FreeS/WAN tells me that the tunnel is established (last message in /var/log/messages).

You got "SA established on both" sides, yes?

My configuration is the following:

1st client------1st FreeS/WAN-gateway-----ROUTER-----2nd FreeS/WAN-gateway-------2nd client

eth0---eth0---------------------------eth1---eth1------eth0--eth0-----------------------------eth1----eth0 !Every box is a linux box!

(your notation is hard ot read/"parse" :))

The 1st client has the following config: RedHat7.1, IP: 192.168.200.2 The 1st FreeS/WAN-gateway config is: SuSE 7.1, kernel 2.4.7, eth0: 192.168.100.1,

usually you sould get a "network unreachable" when trying to set a route via 100.1/24 on 200.2/24... They are in different networks. You may wish to change one of the IPs to be in the same network. I wonder why you can ping w/o tunnel. For testing, put both in 100.0/24 and set a default route through 100.1.

eth1: 172.16.100.1, IP-forwarding without masquerading The Router has the following config: SuSE7.1, kernel 2.4.7, eth1: 172.16.100.2, eth0 10.16.100.2, IP-forwarding without masquerading

The 2nd FreeS/WAN-gateway config is: SuSE7.1, kernel 2.4.7, eth0: 10.16.100.1, eth1: 192.168.200.1,

200.1 is bad, since you already used that network on right side. But if you change it to 100.0/24 it would be ok.

IP-forwarding without masquerading The 2nd client has the following config: Windows2000, eth (seems to be a littlebit stupid): 192.168.100.2

Again not in the same network as the router. If you change right to 100.0/24 change it here to i.e. 200.0/24, that means change W2K to 200.2 and give it a default route through 200.1

Every netmask is 255.255.255.0;

If i start ipsec via, ipsec start at the shell, no error (exept the IPv6-bind error) occured. Before starting IPSec the routes, the the clients can pinging each other are set by hand.

Are you really really sure it works? Are you sure that you reached the right target? I cannot believe it.

FreeS/WAN sets the routes to the ipsec0 interface.

It would be interesting to see route -n with and without tunnel (before and after ipsec auto --up ...)

After starting you cannot ping anymore from the 1st client to the 2nd client ans the other way around. Does anybody know a solution for this problem???

Yep, trace it :) in the middle, on "router" you can sniff traffic. On IPSec handshake you should see some UDP:500-->500 packets. The ping through the tunnel should generate IP proto=50 packets with source/destination IP of the gateways (and not with the source from the real client and not with the real destination since it's tunneled). Often you see only packets in one direction but no answers. In this case sniff on next machine and check if the packet gets lost somewhere. On a VPN gw you can sniff on ethX (and you see proto=50) and on ipsecX. On ipsecX you see the decrypted packets and you can check if they look good. If you don't see anything on ipsecX the proto=50 packet was wrong and has been dropped. Check this all and mail the results/details. Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Hi Stefan, On 2001.08.29 06:32:40 +0100 Stefan_Walther@gehag-dsk.de wrote:

hi folks,

I have the following problem. I have an established IPSec-tunnel between 2 boxes.

I'm using SuSE7.1 and FreeS/WAN 1.91. The FreeS/WAN tells me that the tunnel is established (last message in /var/log/messages).

<SNIP>

Before starting IPSec the routes, the the clients can pinging each other are set by hand. FreeS/WAN sets the routes to the ipsec0 interface.

After starting you cannot ping anymore from the 1st client to the 2nd client ans the other way around. Does anybody know a solution for this problem???

Not withstanding everything that has already been said about strange routing etc, there was a similar problem to this on the list a couple of weeks ago. The problem was the ipsec0 interface was being blocked by the firewall at one end of the tunnel. If you have a firewall, make sure that packets can actually get to the tunnel. HTH, Maf.

THX

MfG.

Stefan Walther stefan_walther@gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maf. King Standby Exhibition Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "It is easier to do a job right than to explain why you didn't." - Martin Van Buren ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~