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

Routing / NATing between 2 local subnets

Hi Community,

 

I'm facing an issue of NATing I guess, let me explain:

 

192.168.xxx.200 Mitel phone system

eth0 on the UTM has 192.168.xxx.250

eth1 is an external i-face towards the internet with 46.xxx.16.146

VOIP clients work fine from 192.168.xxx.0/24.

The WLAN has 172.16.48.0/22.

Clients from the WLAN can connect but I can't hear the voice from other phones on the WLAN client.

 

Weirdly, the client IP that shows on the Mitel when connecting from WLAN is 192.168.xxx.250

 

But the more interesting is this in the log:

 

2017:03:24-12:49:44 vpn ulogd[22881]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="42578" dstport="5060"

 

Any idea are appreciated!



This thread was automatically locked due to age.
Parents
  • Do you have any NAT-rules for the WLAN segment to the 192.168.x.0/24 subnet?

    The dropped packet looks to be standard SIP (TCP port 5060, app 445) traffic which is not allowed in the firewall, that one could be "repaired" with a SIP traffic allow rule from WLAN to 192.168.x.0 segment. However, beware there's also RTP traffic on multiple ports. Port 5060 is only for signalling.


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • Hi, thanks for the reply.

     

    Yes, there's a masquerading rule for WLAN -> LAN

    What is weird is that the traffic should not go to the uplink interface, but to the LAN and PBX...

  • If traffic isn't flowing how you suspect, the first place to look at is routing. Traffic heading out to the internet etc is a sign that the UTM doesn't know how to route/resolve the address it's trying to get to.

    All clients in your example will need to know how to get to each other to create the RTP stream.

    As mentioned, SIP is for signalling only. RTP has to be opened in both directions to actually hear the voice.

  • Hi Louis-M,

     

    that's what I thought as well, but I can't imagine why this should happen.

     

    Here is some more log entries. There are some packets going through properly, that's why I don't understand the issue:

     

    2017:03:27-13:39:09 vpn ulogd[31114]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="45046" dstport="5060"
    2017:03:27-13:39:09 vpn ulogd[31114]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="12" initf="wlan2" outitf="eth0" mark="0x15b7" app="1463" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="192.168.xxx.200" proto="17" length="48" tos="0x18" prec="0xa0" ttl="63" srcport="7076" dstport="5006"
    2017:03:27-13:39:09 vpn ulogd[31114]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="12" initf="wlan2" outitf="eth0" mark="0x15b7" app="1463" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="192.168.xxx.200" proto="17" length="48" tos="0x18" prec="0xa0" ttl="63" srcport="7077" dstport="5007"
    2017:03:27-13:39:10 vpn ulogd[31114]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="45046" dstport="5060"
    2017:03:27-13:39:10 vpn ulogd[31114]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="45046" dstport="5060"
    2017:03:27-13:39:11 vpn ulogd[31114]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="45046" dstport="5060"
    2017:03:27-13:39:13 vpn ulogd[31114]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan2" mark="0x1bd" app="445" srcmac="38:a4:ed:b4:c2:xx" dstmac="00:1a:8c:0a:1a:xx" srcip="172.16.48.111" dstip="46.xxx.16.146" proto="17" length="341" tos="0x00" prec="0x00" ttl="64" srcport="45046" dstport="5060"

     

    Here we can see that the PBX is sending replies to the gateway at the internal ETH0 adapter address.


    2017:03:27-13:47:28 vpn ulogd[31114]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="12" initf="eth0" mark="0x1a7" app="423" srcmac="00:08:5d:8d:8d:xx" dstmac="00:1a:8c:5f:52:xx" srcip="192.168.xxx.200" dstip="192.168.xxx.250" proto="17" length="200" tos="0x18" prec="0xa0" ttl="64" srcport="5004" dstport="7076"

     

    The question is: How can I have the PBX get to know the real address of the SIP client connected on the other network?

  • NAT and SIP don't go well together. You may need to use STUN.

    If both (SIP client and SIP server) are in your own network, than really try to not use NAT but use standard routing instead. It's so much easier....


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • Thanks for the hint.

     

    As much as I'd like to switch to STUN for internal routing of SIP, it would probably break (at least until debugging) the setup to the external SIP trunk.

     

    Is there no other good way?

  • "... there's a masquerading rule for WLAN -> LAN"

    Needing such a rule is an indication of a misconfiguration in WebAdmin.  Check your config against #3 through #5 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi  ,

     

    I don't understand whats wrong in the NAT Masquerading rule?

     

    Best regards
    David

  • There's nothing wrong with it, David, but the fact that you need it indicates a configuration error.  WebAdmin is a GUI that manipulates databases of objects and settings.  A single change there can cause the Configuration Daemon to rewrite hundreds of lines of the code used to run the UTM.  WebAdmin automatically creates routes between all subnets defined on its Interfaces.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Well, at this point I feel a bit stupid...

    I just disabled that NAT rule, and it works just fine!

     

    Next time I'll RTFM ;)

     

    Thanks for all the support, I try to help whenever I can!

Reply Children
No Data