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 <n...@familie-kuntze.de> 06/04/2015 18:01 >>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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@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@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVIrv0AAoJEDg5KY9j7GZYS38P/RZaq4rqqTIw0eemgefSDDZC
NsaawfRygUNdchScAKwGBI6UdyhNefcnhzijR5NTeB3SxWB++z1IkTsoyPYBhzT/
PMWk0dIPJ+AkxbSib0ocLUVZ/HMPPHAyRmzTDONaKSZ2e6GfyRNqyqG9+66sRmHL
hzc6Vx25sclnGwbYCTdMJYQfNm+9AKjY0aE+qSC91MiSs5EbCBm0IegRd8UVcD9P
DC9j2AiZPd1zvB1coX4JsrhXS6Aai8nc8rrfbxzl1UDqyWtqq/jYFazOdDqP17rz
M2QAcZbnsjneXmJGsYacZWXvZ+AUHcRaapE2G4+W3Ru4EhU+I27lYk7wg1zKjHWa
QPP4LuplE8lje+268aqmj+vpn2dw29P+wk5VtsC3JIQ7OfeZHSAo6fZMUMy0JOsx
rqSAldahxg3hVoJHTKgAUMNaM2iKDBYRTvnpwSL54zr7dn9SVqqM+fWrULC8nZCr
c004wnoHR/dccpD5+VOVcqQwCwqn9qKowZYeDkMLyAxq2DkS6SqgUtPa2uNX0G8D
s3hDRwhCpbGNsCgkF8AvU9b0+eP+fAEenHjIg6JC3GkXPVAvuL35mDbrDYFQq1UW
4CmiymtlUGnqqG9grELiIZlJSeimSDZbfgA+15X2wEqbq8lezHSJ8PsoIQXNNBFm
6SjEdSMJtIn3xqQMELVX
=hnPU
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users@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, and is
believed to be clean.
--- Begin Message ---
Hi,
Sorry for my previous mail, this time with some content:
> I have only started running into this since we started using more than
> one subnet in the left side of the connection.
> leftsubnet=10.176.0.0/13,10.130.0.0/16
> rightsubnet=192.168.0.0/16
> Iona-VPN-FW[1]: IKEv2 SPIs: 550d0c34bc66ce4e_i* da285a283fb7a4d1_r, rekeying
> in 23 hours
> Iona-VPN-FW{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ccb6a085_i ad93852a_o
> Iona-VPN-FW{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (9 pkts,
> 2965s ago), rekeying in 33 seconds
> Iona-VPN-FW{1}: 10.176.0.0/13 === 192.168.0.0/16
> Iona-VPN-FW{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c01ce92f_i 0a7d4641_o
> Iona-VPN-FW{2}: AES_CBC_128/HMAC_SHA1_96, 2479 bytes_i (17 pkts, 3272s
> ago), 4873 bytes_o (15 pkts, 3272s ago), rekeying in 2 seconds
> Iona-VPN-FW{2}: 10.130.0.0/16 === 192.168.0.0/16
Actually, what you have configured and what got negotiated doesn't
really match. If you have multiple subnets in a connection, these should
get negotiated in a single CHILD_SA. However, you have multiple
CHILD_SAs, most likely because your peer prefers to negotiate that.
You may try to configure separate CHILD_SAs for your subnets. With
ipsec.conf, you'll have to define separate "conn" entries with the same
base settings, but different subnet configurations. charon automatically
merges such configurations to negotiate them under the same IKE_SA.
> Mar 4 16:58:14 ip-10-180-0-12 charon: 16[ENC] generating CREATE_CHILD_SA
> request 2 [ N(REKEY_SA) SA No TSi TSr ]
> Mar 4 16:58:14 ip-10-180-0-12 charon: 16[NET] sending packet: from
> 10.180.0.12[4500] to 2.2.2.2[4500] (332 bytes)
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[NET] received packet: from
> 2.2.2.2[4500] to 10.180.0.12[4500] (236 bytes)
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[ENC] parsed CREATE_CHILD_SA
> response 2 [ SA No TSi TSr ]
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x00000000) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same
> policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x00000000) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x00000000) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same
> policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x00000000) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[IKE] unable to install IPsec
> policies (SPD) in kernel
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[IKE] failed to establish CHILD_SA,
> keeping IKE_SA
Because of this mismatch between configuration and negotiated SAs, it
seems that when rekeying the selectors negotiated do not match the
previous CHILD_SA, but the other one separately negotiated.
I think you should change your configuration to use separate CHILD_SAs,
or try to negotiate all subnets under a single CHILD_SA on the Cisco
side. If that doesn't work, you may try a build from git sources; we
recently merged changes that avoid these policy conflicts. But most
likely you'll end up with the wrong selectors after rekeying the
CHILD_SA.
Regards
Martin
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--- End Message ---
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
