Mailinglist Archive: opensuse-security (511 mails)
| < Previous | Next > |
Re: [suse-security] FreeS/WAN tunnel established, no data transferred
- From: Steffen Dettmer <steffen@xxxxxxx>
- Date: Wed, 29 Aug 2001 09:58:04 +0200
- Message-id: <20010829095804.D2325@xxxxxxxxx>
* Stefan_Walther@xxxxxxxxxxxx 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.
> 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.
| < Previous | Next > |