Dialup VPN only working one way

VPN
1

I have the following scenario:

Site A: A Fortigate with a static public IP

Site B: Fortigate 40F 3G4G with a SIM card inserted, no static IP.

I created an ipsec tunnel between those two firewalls. On site A, I configured the Remote Gateway as “Dialup User”, NAT Traversal is enabled. I created the Security Policies and the static routes on both sites.

Now, the problem is:

From site B, I can ping an ip address on site A. However, I can’t ping from site A to site B. In the sniffer, I can see the packet leaving site A:

13.920003 redinf1.vl20 in 192.168.81.125 → 172.22.250.50: icmp: echo request

13.920058 VPN out 192.168.81.125 → 172.22.250.50: icmp: echo request

But on site B, it seems like nothing is arriving.

What am I missing?

2

Lookup the Diagnosis Debug Flow commands

That will tell you what the gate is doing with the traffic.

Packet capture is a good tool but not the right one for this problem.

3

It’s working now. I deleted the static route on site A, and now it’s working.

I don’t get it… I always thought you need to create this static routes on a Fortigate.

4

agreed - a packet capture’s told you everything it can about the situation. diag debug flow on the receiving end would tell you why the packets getting dropped.

5

static routes don’t work on a dialup hub. You can’t specify which of the dynamic tunnels should the route point to. The only way to solve routing from hub to spokes is either dynamic routing (BGP, OSPF, RIP), or IKE-based routes. (spokes “announce their subnets” through phase2 selectors)

6

Thanks for your explanation. However, I still don’t get why the communication from site B to site A worked if my routing config was false.

7

Good question, but ultimately pointless, given the limitation outlined. (why bother if you can’t use that solution anyway)

If I were to guess, then perhaps for some arcane edge-case reason the ambiguous route is somehow sufficient to pass reverse-path check (you know which specific tunnel the packet is coming from = have egress interface for reply direction; and there’s a route vaguely pointing into the dialup tunnel interface). Maybe it would have broken completely if a second dialup spoke connected?
For sessions in the reverse direction, that would not help, since the egress interface is not yet known.