[strongSwan] Routing Polices with IPTABLES not working

Sat Dec 8 23:52:18 CET 2012

Yeah I am running v5.0 and the leftnexthop has been removed..... :(

I am looking into setting some static routing on my updown script that can be run each time or have a permanent route in place for all my virtual ip address as they arrive.

Regards,

Adrian Milanoski
Lab Administrator
BBOS WiFI VPN. Security Testing - R&D
Research In Motion Limited
Tel.(289) 261-5801 | Cel: (647) 289-261-5801
Email  amilanoski at rim.com<mailto:amilanoski at rim.com>

[Description: Description: www.rim.com]<http://www.rim.com/>[Description: Description: cid:image001.png at 01CB37B8.EC492D80]

From: fred.demers at gmail.com [mailto:fred.demers at gmail.com] On Behalf Of Frédéric Demers
Sent: Saturday, December 08, 2012 5:41 PM
To: Adrian Milanoski
Cc: Andreas Steffen; Users at lists.strongswan.org
Subject: Re: [strongSwan] Routing Polices with IPTABLES not working

I was able to get this working in the hub and spoke configuration with both spokes exchanging through the tunnels, but I had to use the virtual IP feature and use the private addressing scheme between the spokes. This forced my traffic through the tunnels, and they were forwarded through the hub.
I also found that I needed to use the left/rightnexthop statement (maybe only needed in IKEv1) otherwise the hub could not reach the spokes, even though the spokes could reach each other through the hub and the spokes could independently reach the the hub. This was rather odd because the hub should have known how to route to each spoke (and was doing so during packet forwarding), but not if I used a terminal window to reach either spokes. With the left/rightnexthop, it worked (under limited testing).
On 8 December 2012 17:36, Adrian Milanoski <amilanoski at rim.com<mailto:amilanoski at rim.com>> wrote:
Hi Andrew,

IP forwarding is enabled

cat /proc/sys/net/ipv4/ip_forward
1

The packets are not getting NAT'd after they arrive back to my GW.

They are going back out my public as the originating IP that it was given from the virtual ip pool. E.g. 172.16.24.x

I may also add that I have only 1 default GW on my GW and that is for the public. I do not have a GW set for my private network.

I am trying to get it so that any packets that come from  172.16.24.x go back out to the private interface or to the default GW for that matter.

Regards,

Adrian Milanoski
Lab Administrator
BBOS WiFI VPN Dev. Security Testing
Research In Motion Limited
Tel.(289) 261-5801<tel:%28289%29%20261-5801> | Cell: 647-289-6995<tel:647-289-6995>
Email  amilanoski at rim.com<mailto:amilanoski at rim.com>

-----Original Message-----
From: Andreas Steffen [mailto:andreas.steffen at strongswan.org<mailto:andreas.steffen at strongswan.org>]
Sent: Friday, December 07, 2012 4:15 AM
To: Adrian Milanoski
Cc: Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
Subject: Re: [strongSwan] Routing Polices with IPTABLES not working

Hi Adrian,

have you enabled IP forwarding on your VPN gateway?

  echo 1 > /proc/sys/net/ipv4/ip_forward

If yes, do you NAT packets from the private network behind the
gateway going towards the Internet?

If yes then you must exempt packets from the private network that
are intended to go through the IPsec tunnel from NAT with the
following iptables rule:

  iptables -t nat -I POSTROUTING 1 -s <private network> -o eth0 \
           -m policy --dir out --pol ipsec --proto esp -j ACCEPT

Regards

Andreas

On 06.12.2012 19:37, Adrian Milanoski wrote:
> HI All,
>
> I have a strongSwan 5.0 setup and configure using IKEv2 PSK in config
> mode with the GW providing a pool of addresses. However after the
> strongSwan client connects I can only ping the Private interface of the
> VPN GW.
>
> I was wondering if anyone can assist me with what maybe going on and why
> packets are not routing out the private interface to the private
> networks default GW.
>
> Why is it so difficult to get these packets flowing from the tunnel to
> the private network? I thought the certain commands were to add rules in
> to the IPtables and remove them when the tunnel is torn down.
>
> Any help would be much appreciated.
>
> *Regards,***
>
> */ /*
>
> */Adrian Milanoski/*
> BBOS Lab Administrator
>
> VPN / WLAN IOT / Pre-Cert
>
> Research In Motion Limited
> 4715 Tahoe Blvd, Mississauga,
> ON, Canada, L4W 0B5
> Tel.(289) 261-5801|Fax (905) 629-7836
> Email amilanoski at rim.com<mailto:amilanoski at rim.com> <mailto:amilanoski at rim.com<mailto:amilanoski at rim.com>>**
>
>
>
>
>
>
>
> Description: www.rim.com<http://www.rim.com> <http://www.rim.com/>Description:
> cid:image001.png at 01CB37B8.EC492D80
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org<mailto:andreas.steffen at strongswan.org>
strongSwan - the Linux VPN Solution!                www.strongswan.org<http://www.strongswan.org>
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20121208/260f0770/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2268 bytes
Desc: image001.jpg
URL: <http://lists.strongswan.org/pipermail/users/attachments/20121208/260f0770/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 1655 bytes
Desc: image002.jpg
URL: <http://lists.strongswan.org/pipermail/users/attachments/20121208/260f0770/attachment-0001.jpg>