Configuring VPN Remote Access for the first time on your Sophos XG Firewall? Check out this useful Community post!
Advisory: Sophos XG Firewall - Antivirus service stopped due to failed pattern update. Please visit this KBA for the latest updates
We'd love to hear about it! Click here to go to the product suggestion community
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?
Jim, make sure to open the ports needed.
For DNAT, use the following KB:
In reply to lferrara:
I have firewall rules and nat rules for this connection.
Situation: VOIP PBX as VM inside the LAN, one trunk.
I only have this FW rule, no NAT rule.Works fine for me.
In reply to Peter-Paul Gras:
Sometimes you have to reload the SIP Helper.
Thanks for responding.
I not sure how you can not have a nat rule? Unless your sip trunk is registering with the provider in that case it uses the standard outbound nat rule to get out and registers with the Provider.
My specific provider it not registering the trunk. It is sending a call to my Public IP address via sip. SO i have to direct that sip traffic to my Cisco CUBE router via the nat rule.
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.
In reply to Jim Boothe1:
Yes, indeed my trunk registers with the the VOIP provider so it will use the default NAT rules.
can you share what configuration you changed on your SIP provider?
Any details about how ASA handles this?
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:email@example.com:5060 SIP/2.0Via: SIP/2.0/UDP 184.108.40.206:5060;branch=z9hG4bK1sansay2766498rdb139Record-Route: <sip:firstname.lastname@example.org:5060;lr;transport=udp>To: <sip:email@example.com>From: "Caller ID" <sip:firstname.lastname@example.org>;tag=sansay2766498rdb139Call-ID: email@example.comCSeq: 1 INVITEContact: <sip:firstname.lastname@example.org:5060>Supported: timer,100rel,replacesSession-Expires: 600;refresher=uacMin-SE: 90P-Asserted-Identity: "Caller ID" <sip:email@example.com:5060>Max-Forwards: 69Content-Type: application/sdpContent-Length: 305
v=0o=Sansay-VSXi 188 1 IN IP4 220.127.116.11s=Session Controllerc=IN IP4 18.104.22.168t=0 0m=audio 11042 RTP/AVP 0 8 18 101a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=sendrecva=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 OKVia: SIP/2.0/UDP 22.214.171.124:5060;branch=z9hG4bK2sansay2766498rdb139From: "Caller ID" <sip:firstname.lastname@example.org>;tag=sansay2766498rdb139To: <sip:email@example.com>;tag=F5299B8-D11Date: Mon, 24 Feb 2020 06:48:39 GMTCall-ID: firstname.lastname@example.orgCSeq: 2 INVITEAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTERAllow-Events: telephone-eventRemote-Party-ID: <sip:email@example.com>;party=called;screen=no;privacy=offContact: <sip:firstname.lastname@example.org:5060>Record-Route: <sip:email@example.com:5060;lr;transport=udp>Supported: replacesSupported: sdp-anatServer: Cisco-SIPGateway/IOS-15.5.3.M4aRequire: timerSession-Expires: 1800;refresher=uacSupported: timerContent-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 247
v=0o=CiscoSystemsSIP-GW-UserAgent 1350 3702 IN IP4 172.16.135.2s=SIP Callc=IN IP4 172.16.100.2t=0 0m=audio 18080 RTP/AVP 0 101c=IN IP4 172.16.100.2a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=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.0Record-Route: <sip:126.96.36.199:5060;lr>From: <sip:+firstname.lastname@example.org:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0cTo: <sip:+130425554444@Public IP>CSeq: 3037 INVITEMax-Forwards: 62Call-ID: email@example.comVia: SIP/2.0/UDP 188.8.131.52:5060;branch=z9hG4bKbca9.ca04ac75.0Via: SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658Contact: <sip:+firstname.lastname@example.org:5060;transport=udp>Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFYUser-Agent: Twilio GatewayX-Twilio-AccountSid: AC4ae81b353ede92009eaa8dcab18e14abContent-Type: application/sdpX-Twilio-CallSid: CA1e31fd9977b8dbc7af863c01276413deContent-Length: 278
v=0o=root 1612282389 1612282389 IN IP4 184.108.40.206s=Twilio Media Gatewayc=IN IP4 220.127.116.11t=0 0m=audio 18110 RTP/AVP 0 8 101a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20a=maxptime:150a=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 OKVia: SIP/2.0/UDP 18.104.22.168: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-444794762458710658From: <sip:+email@example.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0cTo: <sip:+13045558888@Public IP;tag=2CAF75D6-64BDate: Mon, 24 Feb 2020 07:27:16 GMTCall-ID: firstname.lastname@example.orgCSeq: 3037 INVITEAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTERAllow-Events: telephone-eventRemote-Party-ID: "Jim Boothe" <sip:email@example.com>;party=called;screen=yes;privacy=offContact: <sip:+firstname.lastname@example.org:5060>Record-Route: <sip:22.214.171.124:5060;lr>Supported: replacesSupported: sdp-anatServer: Cisco-SIPGateway/IOS-16.9.5Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259Supported: timerContent-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 236
v=0o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3s=SIP Callc=IN IP4 10.10.7.3t=0 0m=audio 8500 RTP/AVP 0 101c=IN IP4 10.10.7.3a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=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 OKVia: SIP/2.0/UDP 126.96.36.199: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-444794762458710658From: <sip:+email@example.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0cTo: <sip:+13045558888@Public IP;tag=2CAF75D6-64BDate: Mon, 24 Feb 2020 07:27:16 GMTCall-ID: firstname.lastname@example.orgCSeq: 3037 INVITEAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTERAllow-Events: telephone-eventRemote-Party-ID: "Jim Boothe" <sip:email@example.com>;party=called;screen=yes;privacy=offContact: <sip:+13045558888@Public IP5060>Record-Route: <sip:188.8.131.52:5060;lr>Supported: replacesSupported: sdp-anatServer: Cisco-SIPGateway/IOS-16.9.5Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259Supported: timerContent-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 236
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.