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

Ivan Adji - Krstev akivanradix at gmail.com
Mon Oct 5 04:31:19 EDT 2015 

If this is on Hyper-V machine hosted, i think the problem is on Hyper-V. 
Try ping with smaller packets and it will pass. That is half solution 
from my site. And im trying to fix the ping with parameters about packet 
size.

Ivan

On 10/05/2015 10:10 AM, Nick Howitt wrote:
> Hi Cooper,
>
> Firstly let me say I am not sure of the effect of these being EC2 
> instances as these often require a different set up, but:
>
> 1 - why have you set "forceencaps=yes" as this is public IP <-> public 
> IP or are you natted somewhere?
> 2 - Please remove all blank lines inside a conn as a blank line 
> normally means the end of a conn definition.
> 3 - left/rightsource IP is normally set to be the LAN IP of your VPN 
> gateway and not public IP but I am not sure of the requirements of EC2.
> 4 - when you say you have no iptables rules in place do you mean 
> specific to IPsec or are you running without a firewall completely.
> 5 - Can you post your connection log (but cut all the stuff when ipsec 
> starts)
>
> Nick
>
> On 2015-10-05 08:52, Cooper Simmons 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 [1] to be able to ssh
>> to the servers in subnet 10.40.0.0/16 [2].
>>
>> 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 
>>
>> [3]
>>
>> 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 [2]
>>
>> 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 
>>
>> [4]
>>
>> 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 [1]
>>
>> 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 [5]: ICMP echo request,
>> id 47689, seq 1, length 64
>>
>> 07:40:48.310951 IP 52.1.197.54 > 10.40.56.13 [5]: ICMP echo request,
>> id 47689, seq 2, length 64
>> 07:40:49.318979 IP 52.1.197.54 > 10.40.56.13 [5]: 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 [6] 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 [7] brd 10.33.254.255 scope global eth0
>>        valid_lft forever preferred_lft forever
>>     inet 52.1.197.54/16 [8] 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 [9] dev eth0  proto kernel  scope link  src
>> 10.33.254.184
>> 10.40.0.0/16 [2] dev eth0  scope link  src 52.1.197.54
>> 52.1.0.0/16 [10] 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 [6] 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 [11] brd 10.40.255.255 scope global eth0
>>        valid_lft forever preferred_lft forever
>>     inet 52.20.89.24/16 [12] 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 [1] dev eth0  scope link  src 52.20.89.24
>> 52.20.0.0/16 [13] 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
>>
>>
>>
>> Links:
>> ------
>> [1] http://10.33.0.0/16
>> [2] http://10.40.0.0/16
>> [3] 
>> http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.33.0.0/16
>> [4] 
>> http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.40.0.0/16
>> [5] http://10.40.56.13
>> [6] http://127.0.0.1/8
>> [7] http://10.33.254.184/24
>> [8] http://52.1.197.54/16
>> [9] http://10.33.254.0/24
>> [10] http://52.1.0.0/16
>> [11] http://10.40.56.13/16
>> [12] http://52.20.89.24/16
>> [13] http://52.20.0.0/16
>>
>> _______________________________________________
>> Users at lists.openswan.org
>> https://lists.openswan.org/mailman/listinfo/users
>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

More information about the Users mailing list