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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hey Jon,
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.
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 :)
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.
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?
Created on 01-12-2022 08:25 AM Edited on 01-12-2022 08:27 AM
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
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?
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.
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.
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.
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!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1641 | |
1069 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.