Skip to main content
Jond
Jond
New Member
January 11, 2022
Question

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

  • January 11, 2022
  • 3 replies
  • 8264 views

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

3 replies

akileshc
Staff
akileshc
Staff
January 12, 2022

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
JondAuthor
New Member
January 12, 2022

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
JondAuthor
New Member
January 12, 2022

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
Staff & Editor
Debbie_FTNT
Staff & Editor
January 12, 2022

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
JondAuthor
New Member
January 12, 2022

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

Terms & ConditionsAccessibility statement