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, and is
believed to be clean.
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
