Site-to-Site IPSec VPN from private IP

[Negi]

Dear all,

I'm struggling to connect 2 sites with IPSec VPN.

A central firewall has a static public ip address, but the other side is behind nat and it only has private ip address(sometimes dynamically changed).

Phase 1 has been passed, but I got a phase 2 negotiation error.

I found suspicious logs in diag messages:

  ike 0:Remote-IPSec_0: add peer route 169.254.1.1
  ike 0:Remote-IPSec_0: add peer route failed, peer ip=169.254.1.1

Would you please tell me if there is some workaround for this issue?

Phase 2 diag logs:

(omitted Phase 1 negotiation)

ike 0:b674c784d615bb9d/0000000000000000:5298: SA proposal chosen, matched gateway Remote-IPSec
ike 0:Remote-IPSec: created connection: 0x57e33a0 5 180.149.180.99->126.236.145.247:62882.
ike 0:Remote-IPSec:5298: DPD negotiated
ike 0:Remote-IPSec:5298: selected NAT-T version: RFC 3947
ike 0:Remote-IPSec:5298: cookie b674c784d615bb9d/a73a6850fda5c98a
ike 0:Remote-IPSec:5298: ISAKMP SA b674c784d615bb9d/a73a6850fda5c98a key 16:10BDB5369F1683B2117261B395110F9D
ike 0:Remote-IPSec:5298: out B674C784D615BB9DA73A6850FDA5C98A01100400000000(omitted)
ike 0:Remote-IPSec:5298: sent IKE msg (agg_r1send): 180.149.180.99:500->126.236.145.247:62882, len=512, id=b674c784d615bb9d/a73a6850fda5c98a
ike 0: comes 126.236.145.247:27555->180.149.180.99:4500,ifindex=5....
ike 0: IKEv1 exchange=Aggressive id=b674c784d615bb9d/a73a6850fda5c98a len=100
ike 0: in B674C784D615BB9DA73A6850FDA5C98A141004000000000000000064(omitted)
ike 0:Remote-IPSec:5298: responder: aggressive mode get 2nd response...
ike 0:Remote-IPSec:5298: received NAT-D payload type 20
ike 0:Remote-IPSec:5298: received NAT-D payload type 20
ike 0:Remote-IPSec:5298: PSK authentication succeeded
ike 0:Remote-IPSec:5298: authentication OK
ike 0:Remote-IPSec:5298: NAT detected: PEER
ike 0:Remote-IPSec:5298: remote port change 62882 -> 27555
ike 0:Remote-IPSec: adding new dynamic tunnel for 126.236.145.247:27555
ike 0:Remote-IPSec_0: added new dynamic tunnel for 126.236.145.247:27555
ike 0:Remote-IPSec_0: add peer route 169.254.1.1
ike 0:Remote-IPSec_0: add peer route failed, peer ip=169.254.1.1 <-------------- I got failure message
ike 0:Remote-IPSec_0:5298: established IKE SA b674c784d615bb9d/a73a6850fda5c98a
ike 0:Remote-IPSec: set oper up
ike 0:Remote-IPSec_0:5298: no pending Quick-Mode negotiations
ike 0:Remote-IPSec: carrier up

ike 0: comes 126.236.145.247:27555->180.149.180.99:4500,ifindex=5....
ike 0: IKEv1 exchange=Quick id=b674c784d615bb9d/a73a6850fda5c98a:b2020c16 len=444
ike 0: in B674C784D615BB9DA73A6850FDA5C98A08102001B2020C16000001BC448E2 (omitted)
ike 0: comes 126.236.145.247:27555->180.149.180.99:4500,ifindex=5....
ike 0: IKEv1 exchange=Quick id=b674c784d615bb9d/a73a6850fda5c98a:b2020c16 len=444
ike 0: in B674C784D615BB9DA73A6850FDA5C98A08102001B2020C16000001BC448E2 (omitted)
ike 0: comes 126.236.145.247:27555->180.149.180.99:4500,ifindex=5....
ike 0: IKEv1 exchange=Informational id=b674c784d615bb9d/a73a6850fda5c98a:84c1ee31 len=92
ike 0: in B674C784D615BB9DA73A6850FDA5C98A0810050184C1EE310000005C01070 (omitted)

Like the following message shows many times, but Phase 2 negitiation fails...:crying_face:

  ike 0: comes 126.236.145.247:27555->180.149.180.99:4500,ifindex=5....
  ike 0: IKEv1 exchange=Informational id=b674c784d615bb9d/a73a6850fda5c98a:84c1ee31 len=92
  ike 0: in B674C784D615BB9DA73A6850FDA5C98A0810050184C1EE310000005C0107058B5C(omitted)

Thank you.

[seshuganesh]

Hi Team,

I suspect you have not configured dial up vpn propelry on both ends.

Could you please follow this article and make sure you configured it proerly:

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/6896/fortigate-as-dialup-client

Please check and keep us posted

[akristof]

Hi, as my colleague said, verify the tunnel IP address on that device if you manually configured it and verify config on HUB.

[sw2090]

he wrote it is S2S not dial up.

However 169.254.x.x as remote gw...isn't that APIPA and not routeable?

You have to have reachable public ip as remote gw for a s2s since the getways must be able to reach each other for a s2s to work. So that would require some Portforwarding too.

I have s2s here at my homeoffice too. Endpoint here is a FGT that is behind my router that does the internet connection. So Router has to have 500/udp and 4500/udp forwarded to my FGT because it is ipsec (Port 500) and due to NAT we ned NAT-T (4500). 

Except from some ddns issue (because my wan ip is not static) which I am currently analyzing with TAC (and which I consider a bug in FortiOS) it works fine.

If you don't really need S2S for some reason it might tough be easier to switch to dial up.

The only issue here is that dial up does not to auto negotiation...

[akristof]

Hi,

That 169.254.1.1 is APIPA, but it is tunnel interface. And it this case APIPA is legit IP address, you can assign it to tunnels and even build BGP over it, etc. So that should be ok.