Site-to-Site VPN with Dial-UP addressing Mode

[Grumman]

Hello,

I am having a problem creating a site-to site VPN tunnel that has one side behind NAT with dynamic public IP.

I followed the instructions on the below video as the scenario is exactly as mine and that is what I am trying to accomplish but, the FortiGate firewall never dials in (or it tries but it fails...) 

[link]https://www.youtube.com/watch?v=AMVkOVPzOCw[/link]

Can anyone please shed some light?

Thank you in advance,

Thanasis

[ede_pfau · Accepted solution]

Nice video. The only thing they left out is the NAT device in-between which in your scenario is the stumbling step.

Assuming the HQ is set up like shown in the video, let's focus on the dial-up side.

In order to make this work, the gateway router (GW) there needs to do the following:

- allow any traffic from the FGT to the internet

This includes ESP (a protocol apart from TCP or UDP) and/or UDP ports 500 and 4500. That's why "any traffic" is the easy description.

- apply NAT to outgoing traffic so that the HQ FGT will know where to send the reply traffic

- be "blind" to IPsec traffic, that is, the GW should not respond to IPsec traffic at all.

You can watch the connection buildup on both FGTs at the same time. Use these debug commands in the CLI (either console window or ssh):

diag deb ena

diag deb app ike -1

Prepare this on both FGTs. Now start a permanent ping on a host behind the dialup FGT (in Windows "ping -t IP-of-HQ-FGT-internal-port").

On the remote FGT you should see outgoing IPsec traffic, addressing the public remote IP address of HQ.

On the HQ FGT, you should see an incoming request from the remote FGT. The public source IP address will be the one of your GW's WAN port (which probably is dynamic).

Now check for reply traffic from HQ to dialup. You should see this on the HQ side immediately.

If you see it on the remote side as well, all is good. Then it is only a matter of matching parameters to make the tunnel go up.

If not, you have to check your GW why it isn't passing the traffic through.

Hope this will get you started.

[gschmitt]

Is it FortiGate on both sides and do you have control over them?

Does the dial-up device get a public IP on it's internet facing interface (wan1/2)?

[Grumman]

gschmitt wrote:

Is it FortiGate on both sides and do you have control over them?

Does the dial-up device get a public IP on it's internet facing interface (wan1/2)?

Yes, one is a FG60D and the other is a 200D and I have full control over them.

The 60D is the one which has a dynamic IP and it is behind a NAT so the Wan1/2 interfaces get a private IP address...

[ede_pfau · Accepted solution]

Nice video. The only thing they left out is the NAT device in-between which in your scenario is the stumbling step.

Assuming the HQ is set up like shown in the video, let's focus on the dial-up side.

In order to make this work, the gateway router (GW) there needs to do the following:

- allow any traffic from the FGT to the internet

This includes ESP (a protocol apart from TCP or UDP) and/or UDP ports 500 and 4500. That's why "any traffic" is the easy description.

- apply NAT to outgoing traffic so that the HQ FGT will know where to send the reply traffic

- be "blind" to IPsec traffic, that is, the GW should not respond to IPsec traffic at all.

You can watch the connection buildup on both FGTs at the same time. Use these debug commands in the CLI (either console window or ssh):

diag deb ena

diag deb app ike -1

Prepare this on both FGTs. Now start a permanent ping on a host behind the dialup FGT (in Windows "ping -t IP-of-HQ-FGT-internal-port").

On the remote FGT you should see outgoing IPsec traffic, addressing the public remote IP address of HQ.

On the HQ FGT, you should see an incoming request from the remote FGT. The public source IP address will be the one of your GW's WAN port (which probably is dynamic).

Now check for reply traffic from HQ to dialup. You should see this on the HQ side immediately.

If you see it on the remote side as well, all is good. Then it is only a matter of matching parameters to make the tunnel go up.

If not, you have to check your GW why it isn't passing the traffic through.

Hope this will get you started.

[echo · Accepted solution]

Did you check the FortiOS Handbook 5.2? I was able to configure this using that example, page 1587.