I have setup a tunnel between a UBUNTU SERVER linux box and a CISCO ROUTER.
This is what's the topology looks like:
host 1 ------ UBUNTU SERVER IPSEC <---> CISCO ROUTER ------ host 2
| | | |
| | | |
192.168.64.0/24 1.2.3.4 4.3.2.1 10.10.20.0/24
Here's my problem: the tunnel is setup and running correctly. I can definitely ping from the CISCO ROUTER to any host on the 192.168.64.0/24 network. But I can not ping from the 192.168.64.0/24 network to any host on the 10.10.20.0/24 network.
Here's some info:
ipsec.conf:
conn my_vpn
auto=start
authby=secret
ike=aes256-md5
phase2=esp
phase2alg=aes256-md5
type=tunnel
left=1.2.3.4
leftsubnet=192.168.64.0/24
leftnexthop=%defaultroute
leftupdown="ipsec _updown --route yes"
keyingtries=3
keyexchange=ike
pfs=no
right=4.3.2.1
rightsubnet=10.10.20.0/24
ipsec look command output:
XFRM state:
src 4.3.2.1 dst 1.2.3.4
proto esp spi 0x0f9898dd reqid 16385 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(md5) 0xSOMEVALUE
enc cbc(aes) 0xSOMEOHTERVALUE
src 1.2.3.4 dst 4.3.2.1
proto esp spi 0x667b62d8 reqid 16385 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(md5) 0xSOMEVALUE
enc cbc(aes) 0xSOMEOHTERVALUE
XFRM policy:
src 192.168.64.0/24 dst 10.10.20.0/24
dir out priority 2344
tmpl src 1.2.3.4 dst 4.3.2.1
proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24
dir fwd priority 2344
tmpl src 4.3.2.1 dst 1.2.3.4
proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24
dir in priority 2344
tmpl src 4.3.2.1 dst 1.2.3.4
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
XFRM done
IPSEC mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
NEW_IPSEC_CONN mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ROUTING TABLES
default dev ppp0 scope link
10.10.20.0/24 via 1.2.3.GW dev ppp0
1.2.3.GW dev ppp0 proto kernel scope link src 1.2.3.4
Where 1.2.3.GW is 1.2.3.4's gateway.
ipsec verify command output:
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.37/K3.2.0-38-generic-pae (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing XFRM related proc values [OK]
[OK]
[OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [FAILED]
Two or more interfaces found, checking IP forwarding [FAILED]
Checking NAT and MASQUERADEing [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [WARNING]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
I must add: UBUNTU has a ppp0 connection which has its public IP address: 1.2.3.4.
Static route information:
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
10.10.20.0 1.2.3.GW 255.255.255.0 UG 0 0 0 ppp0
Any ideas?
I have had this problem before -- and if your tunnel is up correctly and the Cisco side is pinging through into the 192.168 network, it means your tunnel is up and passing traffic.
If you can't ping back to the Cisco or the 10.10 segment, the problem is not the tunnel.
The problem is -- most likely -- that you are using the Ubuntu box as your firewall for the 192.168 to get to the internet, and as such iptables is set to masquerade network traffic.
The default setup would be something like the following nat rule, assuming eth1 is the public interface:
The problem is, ipsec traffic also goes out eth1, so you try to masquerade that as well.
Insert a rule before the masquerade rule, specifying that ipsec traffic should not be masqueraded but simply accepted, and strongswan will do the rest:
so running
iptables -L -v -n -t natshould give you the following:Notice the accept line precedes the masquerade line -- it matches first and the packets will not be altered.