Cisco Multicast Ping ICMP reply not traverse over Fortigate IPSec

Question

Hi allI am scratching my head for past days and would appreciate fellow community if anyone of you had similar experience.  I am trying to test multicast over Fortigate IPSec.Fortigate version 7.4.3 using EVE-NG VM Cisco IOL using EVE-NG   Diagram and configuration file is like this:https://drive.google.com/drive/folders/1vKQwaPGqhGTgDzZmf8rGQZHmeRi9vST5?usp=drive_link  R6 join IGMP 224.5.5.5 using Lo0 (192.168.11.1)R7 try to send ping 224.5.5.5 from Lo1 (192.168.22.1) Fortigate configuration follow this:https://community.fortinet.com/t5/FortiGate/Technical-Tip-Multicast-traffic-over-site-to-site-IPsec-VPN-with/ta-p/194209#:~:text=set%20multicast-forward%20disable%20set%20multicast-ttl-notchange%20enable%20set%20gui-multicast-policy,mode%3A%20%23%20config%20router%20multicast%20set%20multicast-routing%20enable with addition that I found out that I need to enable PIM at port 3 (connecting to cisco router). By doing this, the router and the fortigate are pim neighbors. also, I found out that the fortigate has to be set with RP (which is set at R7 Lo1 192.168.21.1). The thing is, the ICMP request to 224.5.5.5 from 192.168.22.1 can be sent to the right side fortigate, go through IPSec, and exit left side fortigate without issue, and R6 Lo0 reply the ping with source: 192.168.11.1 and destination 192.168.22.1. this Echo reply  received by the left fortigate and never exit at the right side fortigate.  Is this ICMP reply (unicast) for multicast packet cannot work with IPSEC?  I do not think there should be any blockage in the policy as I allow all any any to and from ipsec interface. Really appreciate if someone can share their experience  thanks a lot!

pminarik · Accepted Answer

IF the echo request is X.X.X.X->224.5.5.5, and the echo reply is Y.Y.Y.Y->X.X.X.X, I would personally expect the reply packet to be dropped as "no session matched", due to the IP mismatching.

I'm not aware of any exceptions being made for multicast-related traffic, and based on my limited experience with basic forwarded multicast, it typically involves two policies: one multicast-policy for the multicast request/advertisement of service, and one "regular" firewall policy for the unicast followup.

I would suggest checking the debug flow on the "left-side FortiGate" to confirm this suspicion:

diag debug flow filter addr 192.168.22.1

diag debug enable

diag debug flow trace start 10

networkprivate · Answer

Hi pminarikAmazing, I follow the diag command above and it shows what you suspect: "no session matched" id=65308 trace_id=11 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.22.1:24->224.5.5.5:2048) tun_id=192.168.100.20 from to-site2. type=8, code=0, id=24, seq=41."id=65308 trace_id=11 func=init_ip_session_common line=6073 msg="allocate a new session-000007ed"id=65308 trace_id=12 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.11.1:24->192.168.22.1:0) tun_id=0.0.0.0 from port3. type=0, code=0, id=24, seq=41."id=65308 trace_id=12 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-192.168.100.20 via to-site2"id=65308 trace_id=12 func=fw_forward_dirty_handler line=405 msg="no session matched"id=65308 trace_id=13 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.22.1:24->224.5.5.5:2048) tun_id=192.168.100.20 from to-site2. type=8, code=0, id=24, seq=41."id=65308 trace_id=13 func=init_ip_session_common line=6073 msg="allocate a new session-000007ee"id=65308 trace_id=14 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.11.1:24->192.168.22.1:0) tun_id=0.0.0.0 from port3. type=0, code=0, id=24, seq=41."id=65308 trace_id=14 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-192.168.100.20 via to-site2"id=65308 trace_id=14 func=fw_forward_dirty_handler line=405 msg="no session matched"id=65308 trace_id=15 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.22.1:24->224.5.5.5:2048) tun_id=192.168.100.20 from to-site2. type=8, code=0, id=24, seq=42."id=65308 trace_id=15 func=init_ip_session_common line=6073 msg="allocate a new session-000007f0"id=65308 trace_id=16 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.11.1:24->192.168.22.1:0) tun_id=0.0.0.0 from port3. type=0, code=0, id=24, seq=42."id=65308 trace_id=16 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-192.168.100.20 via to-site2"id=65308 trace_id=16 func=fw_forward_dirty_handler line=405 msg="no session matched"id=65308 trace_id=17 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.22.1:24->224.5.5.5:2048) tun_id=192.168.100.20 from to-site2. type=8, code=0, id=24, seq=42."id=65308 trace_id=17 func=init_ip_session_common line=6073 msg="allocate a new session-000007f1"id=65308 trace_id=18 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.11.1:24->192.168.22.1:0) tun_id=0.0.0.0 from port3. type=0, code=0, id=24, seq=42."id=65308 trace_id=18 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-192.168.100.20 via to-site2"id=65308 trace_id=18 func=fw_forward_dirty_handler line=405 msg="no session matched"id=65308 trace_id=19 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.22.1:24->224.5.5.5:2048) tun_id=192.168.100.20 from to-site2. type=8, code=0, id=24, seq=43."id=65308 trace_id=19 func=init_ip_session_common line=6073 msg="allocate a new session-000007f2"id=65308 trace_id=20 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 192.168.11.1:24->192.168.22.1:0) tun_id=0.0.0.0 from port3. type=0, code=0, id=24, seq=43."id=65308 trace_id=20 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=00000000 gw-192.168.100.20 via to-site2"id=65308 trace_id=20 func=fw_forward_dirty_handler line=405 msg="no session matched"you really save my doubt, thinking that I am lacking something else in the configuration! Pardon me for a noob question, how does the fortigate know that it is of the same session? why dont fortigate think that the reply is some sort of a new ICMP packet from unicast source to unicast destination and create a new session while waiting for the existing session reply?

Sign up

Login with SSO

Login to the community

Login with SSO