[strongSwan] IPTables NAT Query

Noel Kuntze noel at familie-kuntze.de
Tue Apr 7 13:37:36 CEST 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Tormod,

Okay. But still only one CHILD_SA is up and the other one not.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 07.04.2015 um 13:35 schrieb Tormod Macleod:
> Hi Noel,
> 
> I need the SNAT as the network on the right want to see the traffic originate from the 1.1.1.0/24 range for internal routing purposes.
> 
> I thought (Bryan Duff set me straight) I needed two Child SAs. Because the right device is a Cisco device I had to configure two separate Child SAs rather than do rightsubnet=c,d. It seems the Cisco ASA wants to do it that way and it was causing me problems. Martin Willi previously helped me with this (see attached).
> 
> Cheers,
> 
> 
> Tormod
>
> >>> Noel Kuntze <noel at familie-kuntze.de> 06/04/2015 18:01 >>>
>
> Hello Tormod,
>
> There is a graph[1] that describes the path of the traffic in the kernel.
>
> Why do you believe, that you have to apply SNAT/MASQUERADE?
> By the way, your tunnel setup is wrong.
> You define two IPsec tunnels, but there is only one being used:
>
> >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
>
> You should look for the reason that causes CHILD_SA of "SecurityAssociation-1" to not come up.
> Also, with IKEv2, you can combine the subnets of all SAs into one.
>
> So you can build something like this:
>
> leftsubnet=a,b
> rightsubnet=c,d
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 06.04.2015 um 16:36 schrieb Tormod Macleod:
> > 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVI8F9AAoJEDg5KY9j7GZYEXIP/28fjNsVPRmfZ8pRGR2T4l+u
ke9GzLTIThVP7ev0Syra9mt92IBFhMf115JTjQptQf6QeuXKgNTT0p+nsWyXDdXv
qMYxtmszEd6gLt8u/zactbHMhEk5RWGqpt0gv8XP/ojtzn35l92R0l3VP5EYVSg6
fVUgA4F39d1vT1Qj4RnoRaW3j39m2hD+o5oig4erJfHMITRJlXflBvmiqHneQYP5
OpksYEHco2o4b5bFVLJgC9wzXHhG+DOZxRguVtcbtTLwWdYtsNgYi5281oH7cdqA
fMzJKOnTZk3PbHO5wIsZMnhuvE2FCkY5KchZaFMPr43OFqvBV25rKkT1S9G4x3Qb
5e9G1CYAT/CH2VWmscmhtDECZtsMBvKg3vvGEAZModFwVOwDyhfRjtlnd7K4vJvt
sCxwnMmByKtalDgwqzXwmhirl1Lw/0kF456P2WEH5airHaFXD9/WSM3GUeByr921
u5kzuvYwjASFDujexiGgJlsTfi2vVI3OQscxPYvfZdZKw2fzt22aaZu86BaoqMu6
OMvfE1VF8SqDkkpiyn8E4emEFhiKFFyIq3fPjbA14JYy4YyduLQN3F2kXrbwN8fa
fdQ1ayC+djcm8vTwQCJ56RQaS4Q3BSOAOHonT1e3HCgNUIorzxILSSrihUpbxPfl
7PZpELg8IqPRd+E6K/p5
=n4Hn
-----END PGP SIGNATURE-----



More information about the Users mailing list