IPSec VPN behind DSL router

[JaapHoetmer]

Hi all, I am trying to get an IPSEC connection between two Fortigate devices, where one is behind a static IP address and the other behind a DSL router and uses a dynamic DNS entry. The VPN will not come up, on the firewall with the static address (remote to me) the IPsec phase 1 error shown is

no matching gateway for new request

and on the local firewall that sits behind the DSL router the P-1 process appears to be successful (event log shows a success message for P-1). I have configured both sides according to the FortiGate IPSec VPN handbook, section Dynamic DNS Configuration, using policy-based security policies. Can anyone explain me what the error message means? When I enable debug on the remote end, the only error message I see for ike is :

gw negotiation timeout

[ede_pfau]

I' m not good at guessing but I' d like to comment anyhow: - try to get rid of policy based VPN - the only reason for it to stay is VPN in Transparent Mode. You' ll make your life a LOT easier with interface mode. - in my experience tunnelling through a (cheap) DSL router can be time consuming, hair graying and unsuccessful in the end. Partly because some routers ' detect' IPsec traffic and try to answer themselves instead of handing it over. I assume you have set up the FGT as ' exposed host' or all-ports-no-questions-asked forwarding. Here it depends on what the DSL router will forward. Initially, ESP is used which is a protocol not included in TCP/IP and as such might not be forwarded at all. During negotiations, the FGT changes from ESP to UDP port 500 to UDP port 4500, always assuming you have checked " NAT-traversal" support in phase2 (or 1). Again, some routers just can' t get their act together and see these port changes as new sessions which breaks the tunnel negotiations. And so on and on... To make it short: if you can configure the DSL router as a modem in ' bridged mode' , without any config on it, then it will work almost 100% of the time. You put the PPPoE credentials onto the FGT (interface config for WAN port) so that the FGT dials out to the provider. Apart from central configuration this setup makes sure that the FGT obtains the public WAN IP which might be used in the IPsec config. I' ve setup many locations with a DSL modem/FGT combo with 100% success.

[JaapHoetmer]

Thanks for your comments, Ede. It might be the router where the problem lies. The router terminates a fibre-optic connection that is used for internet access, telephone and internet TV. I have set up TCP and UDP port forwarding on the router to allow the required traffic onwards to the firewall, but this did not help. This week I have unsuccessfully tried to do exactly as you suggested, e.g. put it in bridged mode, set the access credentials on the FG, and allow the firewall to receive the public IP address. Eventhough the mode appears selectable in the interface of the router (' IP Passthrough' ), it apparently is not an allowed mode for it doesn' t seem to be working. So I guess because of the extended services that are being delivered, this may have been blocked. I will give interface mode a try, as you suggest, and will try to get more information on the IP passthrough option of the router. Thanks, have a great weekend.

[JaapHoetmer]

OK - found an interesting article about the router I am using (Swisscom Centro Grande): http://www.sychold.ch/swisscoms-pirelli-centro-grande-offnen This seems to indicate exactly what I said in my earlier post, that the firmware has certain functionality disabled by the ISP and that includes bridged mode. But there is a mode available with all default features, and a return to supported mode is possible. So I' ll be giving this a try. Cheers.

[Jonathan_Montero]

I think this might help.... You have to do a PORT FORWARDING in the DSL router of the following ports... 50(tcp/udp) - Encapsulation Header (ESP) 51(tcp/udp) - Authentication Header (AH) 500(udp) - Internet Key Exchange (IKE) So, when the request get to the DSL, it' s going to send it to the fortinet and they' re going to be able to make the negotiation...

[emnoc]

50(tcp/udp) - Encapsulation Header (ESP) 51(tcp/udp) - Authentication Header (AH) 500(udp) - Internet Key Exchange (IKE)

ESP and AH are protocols number 50 and 51 respectively and not ports. ALso keep in mind NAT-T typically defaults to udp 4500