IPsec VPN Issue - One Way Traffic

VPN
1

Hi All,

I’m really hoping one of you smart people will be able to help as myself and the Fortinet engineer who’s looking at this case are stumped.

We’ve deployed a FG 60E (v6.2.3) onto an incumbent Japanese circuit which uses PPOE (username and pw) and want to create an ipsec VPN back to a palo alto cluster ( PA-3060 v8.1.17) in London. This is probably the 20th deployment we’ve done of this kind for our customer who has satellite offices all over the world so we know the config should work.

The problem is even though we’re seeing the VPN up (both phase 1 and 2) we’re not seeing return traffic when initiated from the FG. For testing, we’re pinging from 10.25.21.1 (FG) to 10.1.10.2 (IP behind PA). On the debug, I can see traffic entering the VPN as expected but that’s it. On the other side, a packet capture shows the PA cluster receives the ping and replies but it seems to never make it through to the other end.

Here are the key config parts of the FG:

config vpn ipsec phase1-interface
    edit "VPN-to-DC"
        set interface "PPPOE"
        set ike-version 2
        set peertype any
        set net-device disable
        set npu-offload disable
        set dhgrp 14
        set remote-gw x.x.70.14
        set psksecret xxxxxx
end

​

config vpn ipsec phase2-interface
    edit "VPN-to-DC-2"
        set phase1name "VPN-to-DC"
        set replay disable
        set auto-negotiate enable
        set keylifeseconds 3600
        set src-subnet 10.25.21.0 255.255.255.0
        set dst-subnet 10.1.0.0 255.255.0.0
    next
end

​

config router static
    edit 0
        set dst 10.1.0.0 255.255.0.0
        set device "VPN-to-DC"
    next
end

​

config firewall policy
    edit 0
        set name "VPN Out"
        set srcintf "Trust"
        set dstintf "VPN-to-DC"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next

​

edit 1
        set name "VPN In"
        set uuid d0319f0a-1551-51ec-36cd-9b969cddfd02
        set srcintf "VPN-to-DC"
        set dstintf "Trust"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

​

config system zone
    edit "Untrust"
        set interface "wan1"
    next
    edit "Trust"
        set interface "internal1" "PPPOE"
    next
end

​

If you need extra info please let me know.

2

Your policy is only in one direction, you need a policy to allow the traffic back as well.

3

Hi All,

We ended up resolving the issue. The magic command was ‘set nattraversal forced’. From what I understand this is normally used when the FG is behind a NAT device which, as far as I’m aware wasn’t the case but who knows what the Japanese device was doing.

4

Hey, I suggest you change the mtu on the ppoe interface.
You could also follow this thread Technical Tip: Cannot view some web sites when usi... - Fortinet Community

Keep us posted.

5

If the echo req is reaching the other end , but not the echo reply, I would look into the routing table to see if there is a route for the return traffic via the PA / VPN or even a traffic capture on the destination host to see if it actually reaches it.

6

FortiGate is a stateful firewall. Return traffic is automatically allowed.

7

Thanks for the article mate, made the change on the outgoing policy and on the PPOE interface. Still no luck though.

8

Echo req and echo reply is seen in captures on the palo alto. Routing table has been checked and there’s a route back to 10.25.21.0/24 on the PAs.

9

So if the far side is initiating the traffic…

10

I thought this as well when configuring on a Palo, but after testing in a lab I did need two security policies for site to site VPN. So yeah you should need a policy for return traffic even though they are stateful firewalls. At least on the Palo Alto firewall.

11

Did you do a diag debug flow ?

https://docs.fortinet.com/document/fortigate/6.2.3/cookbook/54688/debugging-the-packet-flow

Can you post a result of that ?

Can you also post a show full-conf syst int <-want int → ( without sensitive data)

12

Does the other way around traffic work? Encryption domain matches on the PA?

13

Can you create a policy on the FortiGate for the other way around (VPN-to-DC → Trust) and try to ping from a device behind the PA to a device behind the FortiGate? Then check if traffic arrives at the FortiGate.

14

Read OP’s post. He is testing it from the FortiGate.

15

The other remote sites don’t have a return policy but I have added one for testing purposes. I’ll edit the post to show this but no luck im afraid.

16

The PA can’t ping the remote FG no and yes all encryption domain’s match. There used to be more but I’ve scaled them back to just the one.

PA: 10.1.0.0/16

FG: 10.25.21.0/24

17

policy added and no luck im afraid! Edited original post to show policy.