Guest User!

You are not Sophos Staff.

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

General snat behaviour when using multiple objects or networks as source

Hi there,

i have problems with some, but not all, ip phones not registering with an external sip provider via snat.
The snat rule looks like this:  DMZ-Voip (network) --> any --> any | SOURCE TRANSLATION: one of our public IPs.
(For the sake of simplicity, I have selected any as the destination for the time being)
The registration request goes out from 192.168.1.62, but the response comes out at 192.168.1.31.
Registration works on some IP phones, including the .31. where the mapping of the internal to the public one stays correct.
A tcpdump -vni any -s0 port 5060 shows a wrong mapping of the internal IP address on the reply:


13:48:50.003446 IP (tos 0xa0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 640).
    192.168.1.62.5060 > EXT.IP.SIP.PROV.5060: SIP, length: 612
    REGISTER sip:sip.provider.extern.com:5060 SIP/2.0
13:48:50.003560 IP (tos 0xa0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 640)
   195.xxx.xxx.67.1271 > EXT.IP.SIP.PROV.5060: SIP, length: 612
    REGISTER sip:sip.provider.extern.com:5060 SIP/2.0
13:48:50.010149 IP (tos 0x0, ttl 60, id 15929, offset 0, flags [none], proto UDP (17), length 670)
    EXT.IP.SIP.PROV.5060 >195.xxx.xxx.67.5060: SIP, length: 642
    SIP/2.0 401 Unauthorized
13:48:50.010158 IP (tos 0x0, ttl 59, id 15929, offset 0, flags [none], proto UDP (17), length 670)
    EXT.IP.SIP.PROV.5060 > 192.168.1.31.5060: SIP, length: 642
    SIP/2.0 401 Unauthorized

It works immediately when I create a SNAT rule with the single phone with higher priority. However, if I deactivate the single rule again, one would think that the registration would also fail again. But then the SNAT rule mentioned first works again.
It seems to me that a SNAT with several objects or networks does not work correctly. Can anyone confirm this?



This thread was automatically locked due to age.
Parents
  • forgot to mention: Traffic Source was changed also to a network group which contains every ip phone as hosts. Same result.

    Rule type: SNAT
    For traffic from: GroupIPPhones (former DMZ-VoIP (network)
    Using service: any
    Going to: any
    Change the source to: Public IP
    And the service to: unfilled
    Automatic packet filter rule: X (checked)

    btw: can you not edit your own questions?

  • Salut EB and welcome to the UTM Community!

    I think your SIP provider has a problem:

    195.xxx.xxx.67.1271 > EXT.IP.SIP.PROV.5060: SIP, length: 612

    EXT.IP.SIP.PROV.5060 >195.xxx.xxx.67.5060: SIP, length: 642

    My guess would be that it was just chance that the single-phone SNAT appeared to work better.

    Cheers - Bob

    PS The 'Edit' option is behind 'More'.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Salut EB and welcome to the UTM Community!

    I think your SIP provider has a problem:

    195.xxx.xxx.67.1271 > EXT.IP.SIP.PROV.5060: SIP, length: 612

    EXT.IP.SIP.PROV.5060 >195.xxx.xxx.67.5060: SIP, length: 642

    My guess would be that it was just chance that the single-phone SNAT appeared to work better.

    Cheers - Bob

    PS The 'Edit' option is behind 'More'.

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

    That was my first guess of course, because who couldn't configure a simple snat in Sophos UTM? Wink

    Unfortunately, I did not fully understand your explanation of the SIP provider problem. Is it because the source and destination port in the second line is identical? And this could also be the reason why the mapping of the internal IP (192.168.1.62 -> 192.168.1.31) fails?

    bye
    Hannes

  • Yes, Hannes, that was my interpretation of what you showed us, but I'm not a VoIP protocol expert, so maybe we're looking at four lines unrelated to each other but bunched together by circumstance.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • OK, thanks a lot for your effort. Have a nice day.

    Hannes