Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 26 subscribers
  • Views 786 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Inbound SIP RTP traffic flowing out of WAN rather than LAN interface

Chris Haydon

Hi

I am working on an issue a customer is having where they are trying to get some sip trunks to work with a Mitel Connect/Shoretel phone system.

The phone system has a single LAN interface with a private network address; the sip trunk is authenticated via IP address and if we turn off SIP ALG then a packet capture indicates the SIP header isn't having the host identity rewritten correctly in the INVITE and the remote end is rejecting the call as the invite appears to come from the wrong source it seems; with SIP ALG on then we can make a call but are getting one way audio on the calls the site to remote party leg we get audio but the inward audio is missing. On an inbound call the audio works ok in both directions with the SIP ALG on.

The XG has two WAN connections; one on port 2 with the main internet connection on and a separate link on port 4 that does directly to the SIP provider. There is a SNAT rule that handles making sure the IP on the outbound leg based on the source host and destination is appears to be correct and a DNAT rule that should deal with UDP ports 5060 and 6000-40000 inbound.

What we are seeing and don't understand is that whilst inbound the RTP traffic on outgoing calls is logged against the WAN interface from the source IP of the carrier media gateway and destination of the WAN IP of port 4 but then we see a leg that we expect to be on port 1.100 (voice vlan 100) egressing back out of WAN port 4 towards the internet rather than the LAN interface with a destination of 192.168.100.10 which clearly isn't going anywhere and we have validated that is definitely happening with a tcpdump on both the LAN and WAN interfaces.

Any bright ideas on what would cause that to happen and the traffic to a local LAN host be sent out of the wrong interface; we can't see any obvious issue and clearly the inbound calls are working fine which would indicate the DNAT should be working ok when the remote end sends an invite to port 5060 on the XG for an inbound call.

XG is on v18.



This thread was automatically locked due to age.
Parents
  • FormerMember
    +1 FormerMember

    Hi ,

    Thank you for reaching out to Sophos Community.

    Chris Haydon said:
    What we are seeing and don't understand is that whilst inbound the RTP traffic on outgoing calls is logged against the WAN interface from the source IP of the carrier media gateway and destination of the WAN IP of port 4 but then we see a leg that we expect to be on port 1.100 (voice vlan 100) egressing back out of WAN port 4 towards the internet rather than the LAN interface with a destination of 192.168.100.10 which clearly isn't going anywhere and we have validated that is definitely happening with a tcpdump on both the LAN and WAN interfaces.

    So far this is what I understood: 

    For Outgoing calls, inbound(reply) traffic coming from cloud-server(carrier media gateway) is getting logged against WAN interface Port4.

    We expect that traffic to be forwarded on VLAN 1.100 as that's where 192.168.100.10 is located. However, the firewall is sending this packet out to WAN interface Port4.

    Please correct me if I'm wrong or misunderstanding the issue.

    ====================================================

    I believe this could route the precedence issue. If you've got SD-WAN policy configured then I'd suggest changing to 'static sdwan_policyroute vpn'.

    Click here to know more information on 'Set route precedence'.

  • 0 in reply to FormerMember

    We just ended up stripping out the SD-WAN policy as going down the static route for the required 2 IPs for each set of carrier SIP gateways; ultimately as the traffic was being IP authenticated if the gateway goes down there is no benefit failing over or anything fancy as the ITSP will reject outbound calls anyway if they don't originate from the correct leased line and IP address and won't be able to route inbound ones.

Reply
  • 0 in reply to FormerMember

    We just ended up stripping out the SD-WAN policy as going down the static route for the required 2 IPs for each set of carrier SIP gateways; ultimately as the traffic was being IP authenticated if the gateway goes down there is no benefit failing over or anything fancy as the ITSP will reject outbound calls anyway if they don't originate from the correct leased line and IP address and won't be able to route inbound ones.

Children
No Data