Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 41 subscribers
  • Views 4400 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

V18 Sip trunk

Jim Boothe1

I am trying to set up a sip trunk with sophos v18. 

I have a cisco cube router behind sophos xg v18. 

The cube talks sip to cisco Call manager. 

What rules and nat is needed to connect the cisco router with Sip provider? 

I thought it would be as simple as making a nat dnat rule sending the sip traffic hitting our external ip address to the internal ip of the Cisco router. However it is not working as expected. 

I see the sip traffic hit the cisco router and then the sip traffic is continuing on to the call manager and ringing the internal phones. I can even answer the call. But then it disconnect within a few seconds. 

I see the cisco router is sending the sip OK back out to the provider but not seeing a ack back from the provider. 

Coming from ASA word i am used to natting in the ASA and seeing internal ip addresses hitting the cisco cube on the incoming invite.  But with the NAt in the sophos i am seeing the public ip hitting the cube in the invites? 



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to LuCar Toni

    So after a lot of trial and error i found that it was the SIP headers that were causing the issue. My nat rule and firewall rules were correct in letting the traffic in. Sophos just handles sip traffic differnt than what i am used to with a cisco ASA. It does not re-write the headers. So i was seeing public information in the invite headers and header information going back to the provider was sending private information in the headers. 

     

    I had to create sip-profile and change the response in the contact and or remote party id header information as it flowed back out towards my provider to have my public ip information. 

    Now it is working as expected. 

     

    I am not sure if there are any other settings i could have done on the Sophos to make it work more like an ASA or if the XG just designed to work like this. Probably the latter which is fine now that i have a solution i can move forward with new customers. 

     

    Also FYI. Using a different sip provider that uses sip registration i.e. setting username password information to set up the trunk it worked without any issues behind the XG. the Traffic just went out and talked to the providers SBC and registered. The above issue only appeard when sending sip traffic to and from a provider with no registration. 

  • 0 in reply to Jim Boothe1

    Jim,

    can you share what configuration you changed on your SIP provider?

    Any details about how ASA handles this?

    Thanks

  • 0 in reply to lferrara

    So again in my situation i have A sip provider they point towards my external IP address when sending me calls. 

    On the edge i have a XG firewall. Thru this Nat is done and sends the traffic to my Cisco Cube router 

    If the same as above was done with an ASA instead of the XG firewall my sip traffic coming into the cube would look similar to this. 

    Feb 24 06:48:39: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:3045554444@172.16.100.2:5060 SIP/2.0
    Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK1sansay2766498rdb139
    Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
    To: <sip:3045554444@172.16.100.2>
    From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
    Call-ID: 2266226-0-148086546@207.241.166.100
    CSeq: 1 INVITE
    Contact: <sip:3045558888@207.241.166.109:5060>
    Supported: timer,100rel,replaces
    Session-Expires: 600;refresher=uac
    Min-SE: 90
    P-Asserted-Identity: "Caller ID" <sip:3045558888@207.241.166.109:5060>
    Max-Forwards: 69
    Content-Type: application/sdp
    Content-Length: 305

    v=0
    o=Sansay-VSXi 188 1 IN IP4 207.241.166.109
    s=Session Controller
    c=IN IP4 207.241.166.109
    t=0 0
    m=audio 11042 RTP/AVP 0 8 18 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=sendrecv
    a=maxptime:20

     

    The ASA seems to inspect the sip traffic and change the SIP headers as this initial invite was initially send to the public ip address of the ASA. However when this router received it the invites are pointing to the internal IP address of 172.16.100.2. The only Public ip addresses in the invite is the SIP providers public ip. 

    When the call is answered and the router sends OK responses back to the provider it is also sending the internal ip address of the router as the contact See below

    Feb 24 06:48:39: //972717/6ED80257A228/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK2sansay2766498rdb139
    From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
    To: <sip:3045554444@172.16.100.2>;tag=F5299B8-D11
    Date: Mon, 24 Feb 2020 06:48:39 GMT
    Call-ID: 2266226-0-148086546@207.241.166.100
    CSeq: 2 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: <sip:7000@172.16.100.2>;party=called;screen=no;privacy=off
    Contact: <sip:3045554444@172.16.100.2:5060>
    Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
    Supported: replaces
    Supported: sdp-anat
    Server: Cisco-SIPGateway/IOS-15.5.3.M4a
    Require: timer
    Session-Expires: 1800;refresher=uac
    Supported: timer
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 247

    v=0
    o=CiscoSystemsSIP-GW-UserAgent 1350 3702 IN IP4 172.16.135.2
    s=SIP Call
    c=IN IP4 172.16.100.2
    t=0 0
    m=audio 18080 RTP/AVP 0 101
    c=IN IP4 172.16.100.2
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=ptime:20

     

    The ASA changes these headers as it sends back out and the provider receives a sip header with the contact as the public ip address instead of the internal ip address show above. 

     

     

    NOW the xg firewall does not change any of the headers. When the sip invite comes into the router with an XG as the edge devices the router sees the exact same invite that came to the Public ip address. see below

    *Feb 24 07:27:16.058: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:+13045554444@PUBLIC IPSIP/2.0
    Record-Route: <sip:54.172.60.3:5060;lr>
    From: <sip:+13045558888@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
    To: <sip:+130425554444@Public IP>
    CSeq: 3037 INVITE
    Max-Forwards: 62
    Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
    Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0
    Via: SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
    Contact: <sip:+13045558888@172.18.13.233:5060;transport=udp>
    Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
    User-Agent: Twilio Gateway
    X-Twilio-AccountSid: AC4ae81b353ede92009eaa8dcab18e14ab
    Content-Type: application/sdp
    X-Twilio-CallSid: CA1e31fd9977b8dbc7af863c01276413de
    Content-Length: 278

    v=0
    o=root 1612282389 1612282389 IN IP4 34.203.250.95
    s=Twilio Media Gateway
    c=IN IP4 34.203.250.95
    t=0 0
    m=audio 18110 RTP/AVP 0 8 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    a=maxptime:150
    a=sendrecv

     

    So the sip headers have not been "translated" like an ASA does. 

    The router still processes the sip invite and the phone rings. It is answered and RTP traffic starts flowing however when the router sends the OK back out towards the provider it has the internal ip addresses in the headers. The external SIP provider sees this and can not process it as it is a internal ip address so after so many retries the connection is dropped. below is an example 

    *Feb 24 07:27:18.500: //5866/EAB5FB748DF9/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
    From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
    To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
    Date: Mon, 24 Feb 2020 07:27:16 GMT
    Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
    CSeq: 3037 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
    Contact: <sip:+13045558888@10.10.7.3:5060>
    Record-Route: <sip:54.172.60.3:5060;lr>
    Supported: replaces
    Supported: sdp-anat
    Server: Cisco-SIPGateway/IOS-16.9.5
    Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
    Supported: timer
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 236

    v=0
    o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
    s=SIP Call
    c=IN IP4 10.10.7.3
    t=0 0
    m=audio 8500 RTP/AVP 0 101
    c=IN IP4 10.10.7.3
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20

     

    So to fix this i create a sip-profile in the cisco router 

    voice class sip-profiles 100
    response ANY sip-header Contact modify "10.10.7.3" "Public IP"

     

    there are many other headers in the above that you can modify if having problems. Will be different with different sip providers i would imagine on what they are looking for. For example you may need to add the remote-party-ID header as well. 

     

    The above sip profile was then added to the incoming dial-peer of the router. 

     

    so now when the responses go back out to towards the sip provider it looks like the following 

    Sent:
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
    From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
    To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
    Date: Mon, 24 Feb 2020 07:27:16 GMT
    Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
    CSeq: 3037 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
    Contact: <sip:+13045558888@Public IP5060>
    Record-Route: <sip:54.172.60.3:5060;lr>
    Supported: replaces
    Supported: sdp-anat
    Server: Cisco-SIPGateway/IOS-16.9.5
    Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
    Supported: timer
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 236

    v=0
    o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
    s=SIP Call
    c=IN IP4 10.10.7.3
    t=0 0
    m=audio 8500 RTP/AVP 0 101
    c=IN IP4 10.10.7.3
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20

     

     

    I hope this helps the next person trying to work with Cisco behind a Sophos. 

    Also if you are working with a sip provider that you actually have a registered sip trunk where you provide credentials to register the trunk the above should not be involved as the registration process is different and will go out of the xg talk with your sip provider use the handshake with the credentials and the trunk will register and calls will flow through the trunk no problem. The above is only when dealing with NON registered trunks where the provider is sending calls towards our Public ip addess. 

Unfiltered HTML