[Openswan Users] Tunnel up, packets sent through tunnel, but no responses

Cooper Simmons csimmons at square-root.com
Mon Oct 5 04:02:15 EDT 2015


Wanted to also add xfrm policy from each VPN server.

[root at left ~]# ip xfrm policy
src 52.1.197.54/32 dst 10.40.0.0/16
dir out priority 2096 ptype main
tmpl src 10.33.254.184 dst 52.20.89.24
proto esp reqid 16385 mode tunnel
src 10.40.0.0/16 dst 52.1.197.54/32
dir fwd priority 2096 ptype main
tmpl src 52.20.89.24 dst 10.33.254.184
proto esp reqid 16385 mode tunnel
src 10.40.0.0/16 dst 52.1.197.54/32
dir in priority 2096 ptype main
tmpl src 52.20.89.24 dst 10.33.254.184
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main


[root at right ~]# ip xfrm policy
src 52.20.89.24/32 dst 10.33.0.0/16
dir out priority 2096 ptype main
tmpl src 10.40.56.13 dst 52.1.197.54
proto esp reqid 16385 mode tunnel
src 10.33.0.0/16 dst 52.20.89.24/32
dir fwd priority 2096 ptype main
tmpl src 52.1.197.54 dst 10.40.56.13
proto esp reqid 16385 mode tunnel
src 10.33.0.0/16 dst 52.20.89.24/32
dir in priority 2096 ptype main
tmpl src 52.1.197.54 dst 10.40.56.13
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main


Thanks,
Cooper





On Mon, Oct 5, 2015 at 2:52 AM, Cooper Simmons <csimmons at square-root.com>
wrote:

> Hello openswan users,
>
> I was able to set up a tunnel successfully and I am seeing ping and ssh
> getting sent over the tunnel, but I'm not getting responses from the other
> side.
>
> The goal is for servers in subnet 10.33.0.0/16 to be able to ssh to the
> servers in subnet 10.40.0.0/16.
>
> Local/left:
> Public endpoint: 52.1.197.54
> private IP: 10.33.254.184
>
> Remote/right:
> Public endpoint: 52.20.89.24
> private IP: 10.40.56.13
>
>
> ipsec.conf, left side:
> config setup
>   klipsdebug=all
>   plutodebug=control
>   plutostderrlog=/var/log/pluto.log
>   protostack=netkey
>   nat_traversal=yes
>   virtual_private=%v4:
> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.33.0.0/16
>
> conn sr-tunnel
>   authby=secret
>   auto=start
>   forceencaps=yes
>
>   left=%defaultroute
>   leftid=52.1.197.54
>   leftsourceip=52.1.197.54
>
>   right=52.20.89.24
>   rightsubnet=10.40.0.0/16
>
>
>
> ipsec.conf, right side:
> config setup
>   klipsdebug=all
>   plutodebug=control
>   plutostderrlog=/var/log/pluto.log
>   protostack=netkey
>   nat_traversal=yes
>   virtual_private=%v4:
> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.40.0.0/16
>
> conn sr-tunnel
>   authby=secret
>   auto=start
>   forceencaps=yes
>
>   left=%defaultroute
>   leftid=52.20.89.24
>   leftsourceip=52.20.89.24
>
>   right=52.1.197.54
>   rightsubnet=10.33.0.0/16
>
>
>
> status:
> # service ipsec status
> IPsec running  - pluto pid: 17024
> pluto pid 17024
> 1 tunnels up
> some eroutes exist
>
> This is my first time setting up openswan...so be gentle.  ;-)
>
> When I ping from Local/left and run tcpdump on Remote/right I see:
>
> [root at left ~]# ping 10.40.56.13
> PING 10.40.56.13 (10.40.56.13) 56(84) bytes of data.
>
> [root at right ~]# tcpdump -nn icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 07:40:47.303742 IP 52.1.197.54 > 10.40.56.13: ICMP echo request, id
> 47689, seq 1, length 64
> 07:40:48.310951 IP 52.1.197.54 > 10.40.56.13: ICMP echo request, id
> 47689, seq 2, length 64
> 07:40:49.318979 IP 52.1.197.54 > 10.40.56.13: ICMP echo request, id
> 47689, seq 3, length 64
>
>
>
> So it looks to me like packets get to 10.40.56.13 but there is not route
> to get the reply back?
> But there is a route in place.
>
> [root at left ~]# ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
> default
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state
> UP group default qlen 1000
>     link/ether 12:a9:5e:40:e3:67 brd ff:ff:ff:ff:ff:ff
>     inet 10.33.254.184/24 brd 10.33.254.255 scope global eth0
>        valid_lft forever preferred_lft forever
>     inet 52.1.197.54/16 scope global eth0
>        valid_lft forever preferred_lft forever
>     inet6 fe80::10a9:5eff:fe40:e367/64 scope link
>        valid_lft forever preferred_lft forever
>
> [root at left ~]# ip r
> default via 10.33.254.1 dev eth0
> 10.33.254.0/24 dev eth0  proto kernel  scope link  src 10.33.254.184
> 10.40.0.0/16 dev eth0  scope link  src 52.1.197.54
> 52.1.0.0/16 dev eth0  proto kernel  scope link  src 52.1.197.54
> 169.254.169.254 dev eth0
>
>
> [root at right ~]# ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
> default
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state
> UP group default qlen 1000
>     link/ether 12:18:04:de:81:1b brd ff:ff:ff:ff:ff:ff
>     inet 10.40.56.13/16 brd 10.40.255.255 scope global eth0
>        valid_lft forever preferred_lft forever
>     inet 52.20.89.24/16 scope global eth0
>        valid_lft forever preferred_lft forever
>     inet6 fe80::1018:4ff:fede:811b/64 scope link
>        valid_lft forever preferred_lft forever
>
> [root at right ~]# ip r
> default via 10.40.0.1 dev eth0
> 10.33.0.0/16 dev eth0  scope link  src 52.20.89.24
> 52.20.0.0/16 dev eth0  proto kernel  scope link  src 52.20.89.24
> 169.254.169.254 dev eth0
>
> These are EC2 instances and their security groups allow ICMP from
> everywhere.
> I also have no iptables rules (nat or otherwise) in place.
>
>
> Can anyone advise?
> Thanks,
> Cooper
>
>
>
>
>
>
>
>
>


-- 
*Cooper Simmons*
Engineering

*Square Root, Inc. <http://square-root.com/>*
<http://square-root.com/>Square-Root.com <http://square-root.com/>
*[m]* 512.527.4910
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20151005/5563374a/attachment-0001.html>


More information about the Users mailing list