[Openswan Users] Hub and Spoke issue

Nick Howitt nick at howitts.co.uk
Wed Jul 2 10:54:46 EDT 2014


I believe, for example your, your hub SauPaulo-to-Ireland leftsubnets 
must also include Oregon's subnet and so on. Your left/rightsubnets 
should match at either end of the tunnel. If not the non-matching 
element won't route.

Nick

On 2014-07-02 15:33, steve wrote:
> Gaiseric Vandal <gaiseric.vandal <at> gmail.com> writes:
> 
> 
>> 
>> Did you try using the traceroute (linux) on the openswan boxes at the
>> spokes?     Did you try using the traceroute (linux) or tracert (-d)  
>> on
>> network clients at the spokes?
>> 
>> Just so I understand
>> 
>> The San Paulo location is the hub, with private network 10.0.0.0/16
>> 
>> Oregon is spoke 1, with private network 192.168.10.0/24
>> Ireland is spoke 2, with private network 192.168.69.0/24
>> 
>> presumably the traffic is encrypted over vpn  from Oregon to San 
>> Paulo,
>> decrypted at the hub, then reencrypted for the VPN link to Ireland
>> 
>> My guess is that the openswan system or your gateway/router at one 
>> spoke
>> does not have routing information for the private network at the other
>> spoke.     The right subnets info maybe should have been enough.
>> 
>> Depending on your linux version, ip forwarding may not be enabled by
>> default which may be an issue.   (This at least was the case with 
>> fedora
>> core 14.)
>> 
>> To see if routing is enabled
>> 
>>      #sysctl -a | grep  net.ipv4.ip_forward
>> or
>>      #cat /proc/sys/net/ipv4/ip_forward"
>> 
>> Value of 1 means enabled.  This is not the default in FC14
>> 
>> To enable temporarily
>> 
>>      #sysctl -w net.ipv4.ip_forward=1
>> 
>> To enable permantent
>> 
>>      #vi    /etc/sysctl.conf
>>      #net.ipv4.ip_forward=1
>> 
>> If the line is not specifically enabled will default to 0.
>> 
>> On 07/02/14 08:52, steve wrote:
>> > I am trying to get a OpenSwan Hub and spoke working.  I feel like this a
>> > simple problem but I don't know enough Linux to fix it.
>> > All three servers are running Ubuntu 14.10 and the latest OpenSwan
> version
>> >
>> >   I can ping Spoke1 to Hub & Hub to Spoke 1
>> >   I can ping Spoke2 to Hub & Hub to Spoke 2
>> >   I cannot ping Spoke 1 to Spoke 2
>> > Spoke 1
>> >   conn Oregon-to-SauPaulo
>> >           type=tunnel
>> >           authby=secret
>> >           left=%defaultroute
>> >           leftid=54.186.82.78
>> >           leftnexthop=%defaultroute
>> >           leftsubnets=172.31.0.0/16,192.168.10.0/24
>> >           right=54.232.199.31
>> >           rightsubnets=10.0.0.0/16,192.168.69.0/24
>> >           ike=aes256-sha
>> >           esp=aes256-sha1
>> >           pfs=yes
>> >           auto=start
>> >
>> > Spoke 2
>> >   conn Ireland-to-SaoPaulo
>> >           type=tunnel
>> >           authby=secret
>> >           left=%defaultroute
>> >           leftid=54.76.160.103
>> >           leftnexthop=%defaultroute
>> >           leftsubnet=192.168.69.0/24
>> >           right=54.232.199.31
>> >           rightsubnets=10.0.0.0/16,172.31.0.0/16,192.168.10.0/24
>> >           ike=aes256-sha
>> >           esp=aes256-sha1
>> >           pfs=yes
>> >           auto=start
>> > Hub
>> >   conn SauPaulo-to-Oregon
>> >           type=tunnel
>> >           authby=secret
>> >           left=%defaultroute
>> >           leftid=54.232.199.31
>> >           leftnexthop=%defaultroute
>> >           leftsubnet=10.0.0.0/16
>> >           right=54.186.82.78
>> >           rightsubnets=172.31.0.0/16,192.168.10.0/24
>> >           ike=aes256-sha
>> >           esp=aes256-sha1
>> >           pfs=yes
>> >           auto=start
>> >
>> >   conn SauPaulo-to-Ireland
>> >           type=tunnel
>> >           authby=secret
>> >           left=%defaultroute
>> >           leftid=54.232.199.31
>> >           leftnexthop=%defaultroute
>> >           leftsubnet=10.0.0.0/16
>> >           right=54.76.160.103
>> >           rightsubnets=192.168.69.0/24
>> >           ike=aes256-sha
>> >           esp=aes256-sha1
>> >           pfs=yes
>> >           auto=start
>> >
>> > _______________________________________________
>> > 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
>> 
>> 
> 
> 
> Thanks for writing back.
> 
> Server	Ubuntu 14.10
> VPN	OpenSwan 6.3.8
> 
> So the idea is for a user from the outside to hit Oregon on the OpenVPN
> server.  Then that traffic is passed through Sao Paulo then onto 
> Ireland
> where there would be a mail server.
> Sao Paulo has no LAN use.  The mail server would be stood up on that 
> same
> subnet.
> Right now the user who OpenVPNs in can actually ping Sao Paulo too, but 
> I
> wanted to try to get the spokes talking first.
> 
> Here is a little more info.
> This is a test setup in AWS so its a little more complicated
> 
> Spoke 1
> Oregon Public	54.186.82.78  <---This is on AWS
> Oregon Private	172.31.33.163/20    <---This is on eth0, there is no 
> eth1
> Oregon VPC	172.31.0.0/16
> Oregon Subnet	172.31.32.0/20
> Oregon Route Table
> Destination	Target
> 172.31.0.0/16	local  <---local subnet
> 0.0.0.0/0 	igw-2537db40  <---just a default route to the Internet
> Gateway
> 10.0.0.0/16	eni-4bbac12e / i-4114924a  <---this is Sao Paulo's network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 192.168.10.0/24	eni-4bbac12e / i-4114924a  <---this is actually a local
> virtual subnet for OpenVPN users to come into on
> 192.168.69.0/24	eni-4bbac12e / i-4114924a  <---this is Ireland's 
> network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 
> Spoke 2
> Ireland Public	54.76.160.103  <---This is on AWS
> Ireland Private	192.168.69.62/24  <---This is on eth0, there is no eth1
> Ireland VPC	192.168.0.0/16
> Ireland Subnet	192.168.69.0/24
> Ireland Route Table
> Destination	Target
> 192.168.0.0/16  local  <---local subnet
> 0.0.0.0/0	igw-0ff7ed6d <---just a default route to the Internet
> Gateway
> 10.0.0.0/16	eni-3ded3064 / i-9aee61d8  <---this is Sao Paulo's network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 172.31.0.0/16	eni-3ded3064 / i-9aee61d8  <---this is Oregon's network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 
> Hub
> Sao Paulo Public	54.232.199.31  <---This is on AWS
> Sao Paulo Private	10.0.0.12/24  <---This is on eth0, there is no eth1
> Sao Paulo VPC		10.0.0.0/16
> Sao Paulo Subnet	10.0.0.0/16
> Sao Paulo Route Table
> Destination	Target
> 10.0.0.0/16	local  <---local subnet
> 0.0.0.0/0	igw-a6a6b5c4  <---just a default route to the Internet
> Gateway
> 172.31.0.0/16	eni-3e2bc149 / i-be0e03ab  <---this is Oregon's network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 192.168.10.0/24	eni-3e2bc149 / i-be0e03ab  <---this is Oregon's OpenVPN
> virtual network, telling AWS to send it at the Oregon instance so 
> OpenSwan
> can see it
> 192.168.69.0/24	eni-3e2bc149 / i-be0e03ab  <---this is Ireland's 
> network,
> telling AWS to send it at the Oregon instance so OpenSwan can see it
> 
> 
> 
> traceroute Spoke 1 to Spoke 2
> traceroute to 192.168.69.62 (192.168.69.62), 30 hops max, 60 byte 
> packets
>  1  * * *
>  2  * * *
>  3  * * *
>  4  * * *
>  5  * * *
>  6  * * *
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
> 11  * * *
> 12  * * *
> 13  * * *
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
> 
> traceroute Spoke 1 to Hub
> traceroute to 10.0.0.12 (10.0.0.12), 30 hops max, 60 byte packets
>  1  10.0.0.12 (10.0.0.12)  207.328 ms  207.259 ms  207.195 ms
> 
> traceroute Spoke 2 to Spoke 1
> traceroute to 172.31.33.163 (172.31.33.163), 30 hops max, 60 byte 
> packets
>  1  * * *
>  2  * * *
>  3  * * *
>  4  * * *
>  5  * * *
>  6  * * *
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
> 11  * * *
> 12  * * *
> 13  * * *
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
> 
> traceroute Spoke 2 to Hub
>  1  10.0.0.12 (10.0.0.12)  226.837 ms  227.032 ms  226.975 ms
> 
> 
> Routing
> Spoke 1	cat /proc/sys/net/ipv4/"ip_forward"	1
> Spoke 2	cat /proc/sys/net/ipv4/"ip_forward"	1
> Hub	cat /proc/sys/net/ipv4/"ip_forward"	1
> 
> 
> I commented out the default /etc/sysctl.conf and used the one that 
> OpenSwan
> put in /etc/ipsec.d/conf/examples
> 
> # example entries for /etc/sysctl.conf
> # forwarding is needed for subnet or l2tp connections
> net.ipv4.ip_forward = 1
> 
> # rp_filter is stupid and cannot deal decrypted packets "appearing out 
> of
> # nowhere"
> net.ipv4.conf.default.rp_filter = 0
> net.ipv4.conf.all.rp_filter = 0
> 
> # when using 1 interface for two networks when using NETKEY, the kernel
> # kernel thinks it can be clever by sending a redirect (cause it cannot
> # tell an encrypted packet came in, but a decrypted packet came out),
> # so it sends a bogus ICMP redirect
> net.ipv4.conf.all.send_redirects = 0
> net.ipv4.conf.default.send_redirects = 0
> net.ipv4.icmp_ignore_bogus_error_responses = 1
> net.ipv4.conf.default.log_martians = 0
> net.ipv4.conf.all.log_martians = 0
> # seems the martian settings are not always enough. If not receiving 
> packets
> # try running this:
> # for n in eth0 mast0 ipsec0 ipsec1 all default ; do sysctl
> net.ipv4.conf.$n.rp_filter=0; done
> #
> 
> # these are non-ipsec specific security policies you should use
> net.ipv4.conf.default.accept_source_route = 0
> net.ipv4.conf.all.accept_redirects = 0
> net.ipv4.conf.default.accept_redirects = 0
> 
> # When using KLIPS in some situations, you will see errors like:
> # [ 8648.409997] __ratelimit: 168 messages suppressed
> # [ 8648.410009] Neighbour table overflow.
> # Especially when on large cable networks, though we've also
> # seen it when using combinations of xen/bridging/VM's.
> # If you do, and you are SURE there are no routing loops,
> # you can try these below:
> #
> net.ipv4.neigh.default.gc_thresh1 = 1024
> net.ipv4.neigh.default.gc_thresh2 = 2048
> net.ipv4.neigh.default.gc_thresh3 = 4096
> 
> # for enabling core dumps, see
> # http://fcp.surfsite.org/modules/smartfaq/faq.php?faqid=2746
> 
> _______________________________________________
> 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