SSL VPN Portal not getting traffic across IPSEC VPN after updating to v7.0.3

[Jond]

Hi everyone.

What I want to do is access some resources across the IPSEC vpn terminated on the fortigate via the SSL Portal on that same fortigate.  I can't ping the resources from that fortigate and I think it's to do with the originating address and routing, but the Pool previously sorted it!

In v6.4.5 I had a rule for the IP traffic from the SSL Portal that used an IP Pool which meant that the traffic could get across the IPSEC VPNs terminated on the firewall with ease. In 7.0.3 this has stopped working.

Any ideas?

Jon

[akileshc]

Hey Jon,

To analyze the traffic behavior, I propose running the traffic flow debug and sniffers on both firewalls. (Because SNAT is involved, it is preferable to gather logs for the same destination IP address on both firewalls.)

Note: Run the below commands and then initiate Ping towards destination.

Traffic Flow Debug Commands: 

diagnose debug reset

diagnose debug disable

diagnose debug console timestamp enable

diagnose debug flow show fun en

diagnose debug flow filter clear

diagnose debug flow filter addr x.x.x.x -->Destination IP address

diagnose debug flow filter proto 1

diagnose debug flow trace start 1000

diagnose debug enable

After ping fails, disable the logs by executing

diagnose debug disable

Sniffer Commands:

# diagnose sniffer packet any "host x.x.x.x and icmp" 4 0 a

Replace x.x.x.x with destination IP address.

[Jond]

I've now noticed it on other Portals.  It's where the SSL portal traffic is directed through an IPSEC VPN also terminated on the same box.  There is an IP Pool on the rule (on the same interface IP range as the production network) which managed to get around it pre v7.

Will do that debug and post it :)

[Jond]

FGT_601E_FW1 # exec ping 172.16.11.1
2022-01-12 12:53:51 id=20085 trace_id=1 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.243.254:2560->172.16.11.1:2048) from local. type=8, code=0, id=2560, seq=0."
2022-01-12 12:53:51 id=20085 trace_id=1 func=init_ip_session_common line=5955 msg="allocate a new session-0109afc0"
2022-01-12 12:53:51 id=20085 trace_id=1 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface CrawleyIPSEC"
2022-01-12 12:53:51 id=20085 trace_id=1 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel CrawleyIPSEC"
2022-01-12 12:53:51 id=20085 trace_id=1 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
2022-01-12 12:53:52 id=20085 trace_id=2 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.243.254:2560->172.16.11.1:2048) from local. type=8, code=0, id=2560, seq=1."
2022-01-12 12:53:52 id=20085 trace_id=2 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0109afc0, original direction"
2022-01-12 12:53:52 id=20085 trace_id=2 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface CrawleyIPSEC"
2022-01-12 12:53:52 id=20085 trace_id=2 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel CrawleyIPSEC"
2022-01-12 12:53:52 id=20085 trace_id=2 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
2022-01-12 12:53:53 id=20085 trace_id=3 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.243.254:2560->172.16.11.1:2048) from local. type=8, code=0, id=2560, seq=2."
2022-01-12 12:53:53 id=20085 trace_id=3 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0109afc0, original direction"
2022-01-12 12:53:53 id=20085 trace_id=3 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface CrawleyIPSEC"
2022-01-12 12:53:53 id=20085 trace_id=3 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel CrawleyIPSEC"
2022-01-12 12:53:53 id=20085 trace_id=3 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
2022-01-12 12:53:54 id=20085 trace_id=4 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.243.254:2560->172.16.11.1:2048) from local. type=8, code=0, id=2560, seq=3."
2022-01-12 12:53:54 id=20085 trace_id=4 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0109afc0, original direction"
2022-01-12 12:53:54 id=20085 trace_id=4 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface CrawleyIPSEC"
2022-01-12 12:53:54 id=20085 trace_id=4 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel CrawleyIPSEC"
2022-01-12 12:53:54 id=20085 trace_id=4 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
2022-01-12 12:53:55 id=20085 trace_id=5 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.243.254:2560->172.16.11.1:2048) from local. type=8, code=0, id=2560, seq=4."
2022-01-12 12:53:55 id=20085 trace_id=5 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0109afc0, original direction"
2022-01-12 12:53:55 id=20085 trace_id=5 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface CrawleyIPSEC"
2022-01-12 12:53:55 id=20085 trace_id=5 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel CrawleyIPSEC"
2022-01-12 12:53:55 id=20085 trace_id=5 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"
PING 172.16.11.1 (172.16.11.1): 56 data bytes

--- 172.16.11.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

FGT_601E_FW1 # diagnose debug disable

NOTE: I can ping this device from the 10.x network without issue.

[Debbie_FTNT]

Hey Jond,

per the debug, the traffic doesn't match into the VPN P2 selectors for some reason:

2022-01-12 12:53:55 id=20085 trace_id=5 func=ipsec_common_output4 line=792 msg="No matching IPsec selector, drop"

FortiGate is trying to send the traffic into VPN CrawleyIPSEC.

Check the following:
- what policy do you have from SSLVPN (ssl.root) to CrawleyIPSEC?

- what NATing is configured on that policy?

- Is the IP pool intended for NATing included in P2 selectors for the IPSec tunnel on both sides?

[Jond]

Thanks Debbie,

I have a normal policy which had a NAT Pool of addresses within the production network which is within one of the P2 selectors (10.x.x.x/8)

Incoming: ssl.root

Outgoing: CrawleyIPSEC

Source: all

Destination: The hosts

NAT: on

Pool: Use Dynamic (pool: 10.212.135.1 - 10.212.135.254) (P2 selector 10.x.x.x/8)

Main oddity is that... it was working fine yesterday on 6.4.5, today on 7.0.3 it doesn't! :)

I do get a feeling that it might be where the IPSEC connection is address-less... but do you think so?

Cheers

Jon

[Debbie_FTNT]

Hey Jon,

from the config snippets, I don't see an issue - but it doesn't change the fact that debug reported "no matching selectors". Perhaps that particular phase2 is not up, but other phase2 are functional?

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Phase-2-status-in-ipsec-monitor-page/ta-p/...

Other than that, I wouldn't really know what else to check, IPSec is not my main focus in FortiGate, my apologies - you might want to consider open a ticket with FortiGate technical support to get a VPN specialist on your case.

[Debbie_FTNT]

Ah, you mentioned that you can ping from an IP in the 10.x.x.x/8 range above, sorry, I overlooked that.

Then it's probably not a phase2 issue, if the ping works, and I'm completely stumped, apologies.

[Jond]

No problem Debbie

I have a strong feeling that this is to do with self-originating traffic and IPSEC interface IP addresses and will try and pursue that :)

This is a capture of a ping from the firewall across the VPN:

You can see the IP address is particularly wacky - it's a random gateway from another interface (that, incidentally, is not the outgoing WAN i/f) !  Definitely not matching a selector, unfortunately.  Apparently putting IP addresses on the IPSEC interface sorts it somehow.

[Debbie_FTNT]

Hey jond,

this KB might provide some insight into the source IP stuff for IPSec: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Source-IP-for-self-originating-IPsec-tunne...
Though I'm not sure how applicable that is given you mentioned that the IP in question is NOT the wan interface IP.
If you put an IP on the IPSec interface itself, that does give the FortiGate a fixed IP for its self-originating traffic into IPSec VPN, and should resolve any issues with random source IPs.
Alternatively, you can force source IPs for any number of self-originating traffic, such as logging and authentication; the source IPs are usually only configureable via CLI though
#config user radius
#edit <>
#set source-ip x.x.x.x
#end
for example. In 7.0, the source IP settings are expanded, and allow an automatic selection or fixed IP, and even a fixed outgoing interface even if the routing table would dictate a different outgoing interface.
I hope that helps!