Description
This article explains how to use a policy route to correctly route SIP traffic through a FortiGate.
Scope
FortiGate with SIP traffic.
Solution
Some network topologies might require a policy route to have SIP traffic correctly routed through the FortiGate. In this case, it is important that the gateway is not defined in the policy route.
Consider the network topology as shown in the following diagram:
Consider the network topology as shown in the following diagram:
- FortiGate 1 has a static default route via link A.
- FortiGate 2 has a static route to send traffic to subnet 10.0.0.0/24 through link B.
- Both FortiGates use SIP ALG and have policy configured to allow voice traffic.
In the topology, SIP packets from the phone to the SIP server are routed through link A.
SIP packets sent by the server and allowed by an expected session (created by ALG) are routed via link B.
This creates an asymmetric routing condition and the traffic initiated by the SIP server will be dropped by FortiGate 1 if no policy route is in place. It is inadvisable to use this topology or to enabl asymmetric routing in FortiGate 1 (Read this for more details: Technical Tip: How the FortiGate behaves when asymmetric routing is enabled).
This creates an asymmetric routing condition and the traffic initiated by the SIP server will be dropped by FortiGate 1 if no policy route is in place. It is inadvisable to use this topology or to enabl asymmetric routing in FortiGate 1 (Read this for more details: Technical Tip: How the FortiGate behaves when asymmetric routing is enabled).
If the general routing on the FortiGate cannot be modified under these conditions, a policy route can be used as a solution.
1) On FortiGate 2, configure a Policy route to force traffic from the SIP server through link A.
1) On FortiGate 2, configure a Policy route to force traffic from the SIP server through link A.
# config router policy
edit 1
set input-device "WAN"
set src "172.31.31.31/32" (SIP server IP)
set dst "10.0.0.0/255.255.255.0" (Phone subnet)
set output-device "DMZ1"
set src "172.31.31.31/32" (SIP server IP)
set dst "10.0.0.0/255.255.255.0" (Phone subnet)
set output-device "DMZ1"
next
end
2) On FortiGate 2, configure a static route that will indicate the gateway to use.
This route must have a lower priority than the already configured route via link B to avoid interfering with general routing.
# config router static
edit 1 (already configured route)
set dst 10.0.0.0 255.255.255.0
set gateway 12.0.0.254
set priority 20
set device "DMZ2"
next
edit 11 (route added for SIP traffic, works in conjunction with policy route)
set dst 10.0.0.0 255.255.255.0
set gateway 11.0.0.254
set priority 30
set device "DMZ1"
next
end
These settings with a policy route and a lower priority static route will allow the traffic to be routed through the same link in both directions, and will allow SIP ALG to work correctly.
3) Why is it necessary to use a static route instead of a default gateway in policy route?
If a gateway is configured at the policy route level, the traffic handled by SIP ALG on FortiGate 2 will unexpectedly rewrite the destination IP and set it to the gateway IP.
Debug flow output on FortiGate 2
1) The SIP register packet is received and forwarded to the call server with SNAT:
id=20085 trace_id=25801 func=print_pkt_detail line=4511 msg="vd-External received a packet(proto=17, 10.0.0.1:5060->172.31.31.31:5060) from DMZ1. "
id=20085 trace_id=25801 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00e55e39, original direction"
id=20085 trace_id=25801 func=__ip_session_run_tuple line=2613 msg="SNAT 10.0.0.1->188.1.1.250:55656"
id=20085 trace_id=25801 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00e55e39, original direction"
id=20085 trace_id=25801 func=__ip_session_run_tuple line=2613 msg="SNAT 10.0.0.1->188.1.1.250:55656"
2) The register reply is received from the call server and DNAT is applied:
id=20085 trace_id=25802 func=print_pkt_detail line=4511 msg="vd-External received a packet(proto=17, 172.31.31.31:5060->188.1.1.250:55656) from WAN. "
id=20085 trace_id=25802 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00e55e39, reply direction"
id=20085 trace_id=25802 func=__ip_session_run_tuple line=2627 msg="DNAT 188.1.1.250:55656->10.0.0.1:5060"
id=20085 trace_id=25802 func=av_receive line=271 msg="send to application layer"
id=20085 trace_id=25802 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00e55e39, reply direction"
id=20085 trace_id=25802 func=__ip_session_run_tuple line=2627 msg="DNAT 188.1.1.250:55656->10.0.0.1:5060"
id=20085 trace_id=25802 func=av_receive line=271 msg="send to application layer"
3) The packet is routed to link A, DMZ1, but the destination IP of the packet is modified. It has become the Gateway IP configured in Policy route instead of phone IP.
id=20085 trace_id=25803 func=print_pkt_detail line=4511 msg="vd-External received a packet(proto=17, 172.31.31.31:5060->11.0.0.254:5060) from local. "
id=20085 trace_id=25803 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00d5c047, original direction"
id=20085 trace_id=25803 func=resolve_ip_tuple_fast line=4578 msg="Find an existing session, id-00d5c047, original direction"
Debug flow output on FortiGate 1
4) The packet does not match an existing session and is dropped:
id=20088 trace_id=25702 func=print_pkt_detail line=4511 msg="vd-root received a packet(proto=17, 172.31.31.31:5060->11.0.0.254:5060) from DMZ1. "
id=20088 trace_id=25702 func=init_ip_session_common line=4674 msg="allocate a new session-00e56f9b"
id=20088 trace_id=25702 func=fw_local_in_handler line=387 msg="iprope_in_check() check failed on policy 0, drop"
id=20088 trace_id=25702 func=init_ip_session_common line=4674 msg="allocate a new session-00e56f9b"
id=20088 trace_id=25702 func=fw_local_in_handler line=387 msg="iprope_in_check() check failed on policy 0, drop"
