[Openswan Users] RV: IPSec tunnels OK, but don't work VPN

Tomás Alvarez talvarez at ipservice.cl
Sun Mar 9 11:04:34 EDT 2008


>  Hi,

>  I set up a VPN between 2 Fedora Core 5 (Kernel 2.6.15-1.2054_FC5smp)
using OpenSwan 2.4.4

>  Tunnels are OK!

>  # service ipsec status

>     IPsec running  - pluto pid: 23992

>     pluto pid 23992

>     3 tunnels up

>  

>  If I ping from a machine in LAN A to a machine on the remote LAN (B) it
work OK

>  # ping 192.168.20.101

>     PING 192.168.20.101 (192.168.20.101) 56(84) bytes of data.

>     64 bytes from 192.168.20.101: icmp_seq=1 ttl=126 time=53.1 ms

>     64 bytes from 192.168.20.101: icmp_seq=2 ttl=126 time=49.9 ms

>  

>  # tcpdump -nli eth0 proto 50

>     14:37:38.939450 IP XXX.XXX.XX.XX > YYY.YYY.YYY.YYY:
ESP(spi=0x3cec758d,seq=0x3), length 132

>     14:37:38.989187 IP YYY.YYY.YYY.YYY > XXX.XXX.XX.XX:
ESP(spi=0x8a87736f,seq=0x3), length 132

>     14:37:39.940881 IP XXX.XXX.XX.XX > YYY.YYY.YYY.YYY:
ESP(spi=0x3cec758d,seq=0x4), length 132

>     14:37:39.992031 IP YYY.YYY.YYY.YYY > XXX.XXX.XX.XX:
ESP(spi=0x8a87736f,seq=0x4), length 132

>  

>  It see very OK! 
 But when I try any other protocol like SSH, it don’
work from a machine in LAN A to a remote machine in LAN B

>  # ssh 192.168.20.101

>  

>  No ESP traffic is seen in eth0. But I see not encrypted and not NATed
packets in eth0

>  # tcpdump -nli eth0 | grep 192.168.

>     14:44:08.752777 IP 192.168.0.222.51379 > 192.168.20.101.ssh: S
1950168007:1950168007(0) win 5840 <mss 1460,sackOK,timestamp 155885933
0,nop,wscale 2>

>     14:44:11.753190 IP 192.168.0.222.51379 > 192.168.20.101.ssh: S
1950168007:1950168007(0) win 5840 <mss 1460,sackOK,timestamp 155886683
0,nop,wscale 2>

>  

>  In iptables I have the following rule to NAT at eth0:

>     -A POSTROUTING -o eth0 !  -d  192.168.0.0/255.255.0.0 -j MASQUERADE

>  

>  I do exactly the same in WhiteBox and it work fine
 In fedora Core 4 I
have this problem.

>  

>  Any idea what cause this problem?

>  

>  Tomas

>  P.D.: sorry my bad English

>  

 

 

New info about this problem:

 

(192.168.0.0/24) LAN A --- 192.168.0.1 (eth1) [VPN BOX  A] (eth0) ----------
INTERNET ------------- [VPN BOX B] 192.168.20.1 ------ LAN B
(192.168.20.0/24)

If I try to ssh from VPN BOX A to LAN interface of VPN BOX B

 

BOX A # ssh 192.168.20.1

Don’t work, and I see clear packets at WAN interface of 

 

BOX A # tcpdump -nli eth0 | grep 192.168.20

    11:12:21.687338 IP 192.168.0.222.46868 > 192.168.20.1.ssh: S
2071813702:2071813702(0) win 3840 <mss 960,sackOK,timestamp 194964004
0,nop,wscale 2>

    11:12:24.688324 IP 192.168.0.222.46868 > 192.168.20.1.ssh: S
2071813702:2071813702(0) win 3840 <mss 960,sackOK,timestamp 194964754
0,nop,wscale 2>

    11:12:30.688718 IP 192.168.0.222.46868 > 192.168.20.1.ssh: S
2071813702:2071813702(0) win 3840 <mss 960,sackOK,timestamp 194966254
0,nop,wscale 2>

    11:12:42.689504 IP 192.168.0.222.46868 > 192.168.20.1.ssh: S
2071813702:2071813702(0) win 3840 <mss 960,sackOK,timestamp 194969254
0,nop,wscale 2>

 

The new:

I delete the route to 192.168.20.0/24 and create a new route by internal
interface (eth1)

BOX A #  route del -net 192.168.20.0 netmask 255.255.255.0

BOX A # route add -net 192.168.20.0 netmask 255.255.255.0 dev eth1

 

Now I repeate the ssh connection:

BOX A # ssh 192.168.20.1

 

And it work

BOX A # tcpdump -nli eth0 proto 50

    11:17:53.238986 IP (BOX A WAN IP) > (BOX B WAN IP):
ESP(spi=0x7fd6aab2,seq=0xf), length 100

    11:17:53.283125 IP (BOX B WAN IP) > (BOX A WAN IP):
ESP(spi=0x17ba46ec,seq=0xf), length 100

    11:17:53.283202 IP (BOX A WAN IP) > (BOX B WAN IP):
ESP(spi=0x7fd6aab2,seq=0x10), length 100

 

Now VPN works, but just from BOX A to LAN B. Of course I need a VPN from LAN
A to LAN B

 

I’m sure there is not a filtering problem.

 

Any idea about this. Is it a routing issue in Fedora Core 5?

 

Tomas Alvarez

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080309/deee098e/attachment.html 


More information about the Users mailing list