Hello everyone,
I can't get IPsec basic to work site to site with one site behind a NAT (COS is on a DMZ on this NAT).
The master (not NAT'd) has this in the log:
The NAT'd site log:
Config on the Main site:
Config on the NAT's site:
I have ports 500 and 4500 open on each end.
Any help would be appreciated.
Thank you,
Kevin
I can't get IPsec basic to work site to site with one site behind a NAT (COS is on a DMZ on this NAT).
The master (not NAT'd) has this in the log:
Aug 15 07:32:52 isaz-server pluto[1513]: HAVE_STATSD notification support not compiled in
Aug 15 07:32:52 isaz-server pluto[1513]: Setting NAT-Traversal port-4500 floating to on
Aug 15 07:32:52 isaz-server pluto[1513]: port floating activation criteria nat_t=1/port_float=1
Aug 15 07:32:52 isaz-server pluto[1513]: NAT-Traversal support [enabled]
Aug 15 07:32:52 isaz-server pluto[1513]: Could not change to directory '/etc/ipsec.d/cacerts': /
Aug 15 07:32:52 isaz-server pluto[1513]: Could not change to directory '/etc/ipsec.d/aacerts': /
Aug 15 07:32:52 isaz-server pluto[1513]: Could not change to directory '/etc/ipsec.d/ocspcerts': /
Aug 15 07:32:52 isaz-server pluto[1513]: Could not change to directory '/etc/ipsec.d/crls'
....
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [Openswan (this version) 2.6.32 ]
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [Dead Peer Detection]
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [RFC 3947] method set to=109
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Aug 15 07:49:57 isaz-server pluto[1513]: packet from 163.228.132.215:500: initial Main Mode message received on 198.191.124.139:500 but no connection has been authorized with policy=PSK
The NAT'd site log:
Aug 15 07:52:37 isaz2-server pluto[20904]: initiate on demand from 192.168.12.1:51923 to 192.168.11.1:636 proto=6 state: fos_start because: acquire
Config on the Main site:
conn Satellite
type=tunnel
authby=secret
auto=start
left=198.191.124.139
leftsubnet=192.168.11.0/24
right=192.168.112.101
rightsubnet=192.168.12.0/24
leftnexthop=198.191.124.129
leftsourceip=192.168.11.1
rightnexthop=192.168.112.1
rightsourceip=192.168.11.1
Config on the NAT's site:
conn Main
type=tunnel
authby=secret
auto=start
left=192.168.112.101
leftsubnet=192.168.12.0/24
right=198.191.124.139
rightsubnet=192.168.11.0/24
leftnexthop=192.168.112.1
leftsourceip=192.168.12.1
rightnexthop=198.191.124.129
rightsourceip=192.168.11.1
I have ports 500 and 4500 open on each end.
Any help would be appreciated.
Thank you,
Kevin
Share this post:
Responses (3)
-
Accepted Answer
It is easier to configure three sites in a triangle but the more sites you have the more conns you end up defining. his is a PITA if you have a lot of sites. It can also make openswan slow to start but I think you have to have hundreds of tunnels before you really notice it. The other advantage is that communication between, say, site A and site C does not consume site B's bandwidth.. -
Accepted Answer
-
Accepted Answer
On both sides, if in the "config setup" section of ipsec.conf you have "interfaces=%defultroute" you should be able to set left=%defaultroute in your conn and drop the left/rightnexthop parameters.
In both sites, right shoud be the public IP of the far end.
The trick is to get the correct left/rightid and I think on the main side you have to set rightid to the remote site's nat'd IP, 192.168.112.101. Alternatively on the remote site set leftid=left's_public_IP. You may even need both. I can never remember the exact details.
To diagnose you need a different part of the log where it is negotiating main and quick mode. A typical part of the log looks something like:
My setup is different to yours so the logs will be a little different. I only have one side initiating and I use libreswan rather than openswan.Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: responding to Main Mode
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: STATE_MAIN_R1: sent MR1, expecting MI2
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: STATE_MAIN_R2: sent MR2, expecting MI3
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: Main mode peer ID is ID_IPV4_ADDR: '86.6.102.234'
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP2048}
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: Dead Peer Detection (RFC 3706): enabled
Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: the peer proposed: 172.17.2.0/23:0/0 -> 192.168.10.0/24:0/0
Aug 14 13:52:19 server pluto[8547]: "MumIn" #4: responding to Quick Mode proposal {msgid:eb604c25}
Aug 14 13:52:19 server pluto[8547]: "MumIn" #4: us: 172.17.2.0/23===82.19.158.192[@Nick]
Aug 14 13:52:19 server pluto[8547]: "MumIn" #4: them: 86.6.102.234<86.6.102.234>===192.168.10.0/24
Aug 14 13:52:19 server pluto[8547]: "MumIn" #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Aug 14 13:52:19 server pluto[8547]: "MumIn" #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode {ESP=>0xc98ff48a <0xe75a43f3 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=active}
Aug 14 13:52:20 server pluto[8547]: "MumIn" #4: Dead Peer Detection (RFC 3706): enabled
Aug 14 13:52:20 server pluto[8547]: "MumIn" #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug 14 13:52:20 server pluto[8547]: "MumIn" #4: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xc98ff48a <0xe75a43f3 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=active}
I believe the key line is:
This is what the remote end is transmitting as its own leftid and you want to make your rightid match.Aug 14 13:52:19 server pluto[8547]: "MumIn" #2: Main mode peer ID is ID_IPV4_ADDR: '86.6.102.234'
You may also have to manipulate ipsec.secrets in the same way, but to divide the problem, in ipsec.secrets also add %any as an "ip address" to match with. This will allow it to match on any IP with the correct secret. Once you have the tunnel working you can tighten up on this.
Do either of your sites have dynamic WAN IP's?
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »