Description
This article describes a solution for an issue where no audio is audible for phones and debug logs shows the error 'iprope_in_check() check failed on policy 0, drop' even when a policy is configured.
Scope
Any supported version of FortiGate.
Solution
In this example:
- Source IP: x.x.x.x (Public IP)
- VIP IP: y.y.y.y
- PBX IP: z.z.z.z (Private IP)
SIP traffic:
This is based on debug flow. SIP traffic and RTP traffic have 2 different session IDs, 01241d12 and 01241fcc.
Source Packet:
diag debug flow trace start 10002024-02-15 19:24:33 id=20085 trace_id=503 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, x.x.x.x:12367->y.y.y.y:5060) from wan1. "
2024-02-15 19:24:33 id=20085 trace_id=503 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-01241d12, original direction"
2024-02-15 19:24:33 id=20085 trace_id=503 func=__ip_session_run_tuple line=3531 msg="DNAT y.y.y.y:5060->z.z.z.z:5060"
2024-02-15 19:24:33 id=20085 trace_id=503 func=npu_handle_session44 line=1217 msg="Trying to offloading session from wan1 to port1, skb.npu_flag=00000400 ses.state=24100306 ses.npu_state=0x00020000"
2024-02-15 19:24:33 id=20085 trace_id=503 func=fw_forward_dirty_handler line=397 msg="state=24100306, state2=00000341, npu_state=00020000"
2024-02-15 19:24:33 id=20085 trace_id=503 func=av_receive line=314 msg="send to application layer"
Reply packet:
2024-02-15 19:24:51 id=20085 trace_id=529 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, z.z.z.z:5060->x.x.x.x:12367) from local. "
2024-02-15 19:24:51 id=20085 trace_id=529 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-01241d12, reply direction"
2024-02-15 19:24:51 id=20085 trace_id=529 func=__ip_session_run_tuple line=3517 msg="SNAT z.z.z.z->y.y.y.y:5060"
2024-02-15 19:24:51 id=20085 trace_id=529 func=__ip_session_run_tuple line=3568 msg="run helper-null(dir=reply)"
RTP Traffic:
2024-02-15 19:24:52 id=20085 trace_id=530 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, x.x.x.x:12368->y.y.y.y:60580) from wan1. "
2024-02-15 19:24:52 id=20085 trace_id=530 func=init_ip_session_common line=5993 msg="allocate a new session-01241fcc"
2024-02-15 19:24:52 id=20085 trace_id=530 func=vf_ip_route_input_common line=2615 msg="find a route: flag=80000000 gw-y.y.y.y via root"
2024-02-15 19:24:52 id=20085 trace_id=530 func=fw_local_in_handler line=447 msg="iprope_in_check() check failed on policy 0, drop"
For RTP Traffic, since FortiGate thinks this is new session, it is being dropped. The RTP traffic session should match with the SIP session-id which was created.
- SIP debugs show an expectation failed error message:
diagnose debug app sip -1
diagnose debug enable
2024-02-27 19:07:24 sip sess 0x7fb3219e00 vd 0 vrf 0 expectation failed, incorrect arguments redirect: UDP DNAT
If an SIP device has knowledge of the NAT device (FortiGate), it would confuse VOIPD, resulting in a problematic pinhole.
Some VOIP phones can enable STUN-like behavior, attempting to learn the external IP and then set the IP in its SIP payload. This kind of behavior will cause problems: the design principle for FortiGate SIP ALG assumes that it works in a completely transparent way, i.e, SIP entity (SIP phones and SIP servers) on both ends should have no knowledge of whether there is a NAT device in between.
Fix: Disable STUN on the VOIP phone or PBX in a Private network. i.e. do not try to learn the VIP and put the VIP in its payload (in the private network) accessed by external phones via the VIP.
