[strongSwan] IPTables NAT Query

Bryan Duff duff0097 at gmail.com
Mon Apr 6 16:47:28 CEST 2015


If I recall correctly your step 5 is where things matter - make sure at
that point (basically after nat POSTROUTING) that the traffic source/dest
matches your left/rightsubnets.  Don't worry about the routing decision
(your step 3).  You should only need one DNAT and one SNAT for your traffic.

-Bryan

On Mon, Apr 6, 2015 at 9:36 AM, Tormod Macleod <TMacleod at paywizard.com>
wrote:

>  Hello,
>
> I'm currently testing a site to site VPN. I need to change both the source
> and destination address on the left device before forwarding the packets
> over the VPN to the right device. I believe it all happens in the order
> below but I may be wrong.
>
> 1 IPTables Prerouting
> 2 Route selected
> 3 A determination is made on whether the packets should be encapsulated
> with IPSec
> 4 IPTables Postrouting
> 5 Packets are encapsultaed with IPSec where applicable
> 6 Packets are forwarded
>
> I believe I have a solution but I'm not sure whether it's the best and I'd
> welcome some ideas...
>
> In order to have the traffic encapsulated I had to create two child SAs on
> the left side. The first has the original source address and the translated
> destination address. This is only used in step 3. In step 4 the destination
> address is translated and by the time it gets to step 5 the traffic source
> and destination addresses match that of the second child SA which also
> matches the single child SA on the right side.
>
> I'm concerned that I might run into some problems with this approach that
> I have not yet foreseen.
>
> Here's my config...
>
> config setup
>         # strictcrlpolicy=yes
>         # uniqueids=no
>
> conn %default
>         ikelifetime=1440m
>         keylife=60m
>         margintime=3m
>         keyingtries=5
>         keyexchange=ikev2
>         authby=secret
>         left=10.180.0.12
>         leftid=2.2.2.2
>         auto=start
>         ike=aes128-md5-modp1536
>         esp=aes128-sha1
>         reauth=no
>         dpdaction=hold
>         dpddelay=40
>
> conn SecurityAssociation-1
>         leftsubnet=10.176.0.0/13
>         right=3.3.3.3
>         rightsubnet=192.168.0.0/16
>         rightid=3.3.3.3
>
> conn SecurityAssociation-2
>         leftsubnet=1.1.1.0/24
>         right=3.3.3.3
>         rightsubnet=192.168.0.0/16
>         rightid=3.3.3.3
>
>
> Here's the statusall...
>
> [root at localhost ~]# /opt/strongswan522/sbin/ipsec statusall
> Status of IKE charon daemon (strongSwan 5.2.2, Linux
> 2.6.32-504.12.2.el6.x86_64, x86_64):
>   uptime: 3 days, since Apr 03 14:47:09 2015
>   malloc: sbrk 270336, mmap 0, used 210768, free 59568
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 4
>   loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
> pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default
> stroke updown xauth-generic unity
> Listening IP addresses:
>   10.180.0.12
> Connections:
> SecurityAssociation-1:  10.180.0.12...3.3.3.3  IKEv2, dpddelay=40s
> SecurityAssociation-1:   local:  [2.2.2.2] uses pre-shared key
> authentication
> SecurityAssociation-1:   remote: [3.3.3.3] uses pre-shared key
> authentication
> SecurityAssociation-1:   child:  10.176.0.0/13 === 192.168.0.0/16 TUNNEL,
> dpdaction=hold
> SecurityAssociation-2:   child:  1.1.1.0/24 === 192.168.0.0/16 TUNNEL,
> dpdaction=hold
> Security Associations (1 up, 0 connecting):
> SecurityAssociation-1[4]: ESTABLISHED 41 minutes ago,
> 10.180.0.12[2.2.2.2]...3.3.3.3[3.3.3.3]
> SecurityAssociation-1[4]: IKEv2 SPIs: 75498cd903d39dfa_i*
> 9dca56ab7071039a_r, rekeying in 23 hours
> SecurityAssociation-1[4]: IKE proposal:
> AES_CBC_128/HMAC_MD5_96/PRF_HMAC_SHA1/MODP_1536
> SecurityAssociation-2{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cb5e661f_i
> 9add0a95_o
> SecurityAssociation-2{2}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
> rekeying in 48 minutes
> SecurityAssociation-2{2}:   1.1.1.0/24 === 192.168.0.0/16
> And here's the IPTABLES commands I used to send traffic both ways...
>
>   iptables -t nat -A PREROUTING -p tcp -s 10.176.0.10/32 -d 10.180.0.12/32
> --dport 61001 -j DNAT --to-destination 192.168.1.1:23
>   iptables -t nat -A POSTROUTING -s 10.176.0.10/32 -d 192.168.1.1/32 -j
> SNAT --to-source 1.1.1.2
>   iptables -t nat -A PREROUTING -p tcp -s 192.168.1.1/32 -d 1.1.1.3/32
> --dport 61002 -j DNAT --to-destination 10.176.0.10:23
>   iptables -t nat -A POSTROUTING -s 192.168.1.1/32 -d 10.176.0.10/32 -j
> SNAT --to-source 10.180.0.12
> It's a bit convoluted but it works. I'd love to know if someone has a
> better idea.
>
> Cheers,
>
>
> Tormod
>
>   Please consider the environment before printing this email
>    *********************************************************************
>
> This e-mail and any attachments are confidential.  If it is not for you,
> please inform us and delete it immediately without disclosing, copying, or
> distributing it.
>
> If the content is not about the business of PayWizard Group PLC or its
> clients, then it is neither from nor sanctioned by PayWizard Group PLC.
> Use of this or any other PayWizard Group PLC e-mail facility signifies
> consent to interception by PayWizard Group PLC.  The views expressed in
> this email or any attachments may not reflect the views and opinions of
> PayWizard Group PLC.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, but PayWizard Group PLC accepts no liability for any damage
> caused by the transmission of any viruses.
>
> PayWizard Group PLC is a public limited company registered in Scotland
> (SC175703) with its registered office at Cluny Court, John Smith Business
> Park, Kirkcaldy, Fife, KY2 6QJ.
>
> ********************************************************************
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150406/73197cdb/attachment-0001.html>


More information about the Users mailing list