Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 27 subscribers
  • Views 1389 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

Help! NAT that works on UTM9 not working on SF/XG.

DS7109

Hi, hoping someone can help. Apologies for the long post.

*** This looks like a repost from another user but for some reason when I logged in to the community recently it set up a new account for me. I am the OP of this thread**

ALSO, Although in the original thread I thought I'd resolved it, when I put the firewall live the rules/NATs didn't work anymore.  Previously I had configured a pseudo-public IP on the XG which was connected to the UTM, now I'm on a real public IP, this seems to have stopped working.

I'm currently building a Sophos XG appliance to replace my UTM9 as I've exceeded the 50 IP limitation on the home license. Rules and filters etc are slowly but surely being recreated in XG but I've hit a snag with some quite intricate NAT'ing that I'm doing.

I have some security cameras set up (Chinese generic brand) that by default stream all content via some Chinese datacenter servers in AliCloud. To prevent this, I've blocked them at the firewall and access the feeds using a VPN if I need to. The cameras are indoors and while there's not much to see, I'm still not keen on broadcasting my home and family to some unknown datacenter in China.

The way it works is; When I open a camera feed in the app, it scans whatever local network I'm on for a camera on specific ports. It quite literally walks from x.x.x.1 to x.x.x.254 on a range of public and private address spaces. When it finds a camera, it streams from the camera via the internet (or it would if it could). Note that under normal circumstances the app would be connecting to AliCloud to locate the camera, but this is what I've blocked.

For whatever reason the app picks up my mobile carrier's IP address and starts scanning that, even when I'm connected to my VPN. So make this work I've had to configure a fairly convoluted set of IP hosts in a group and a couple of NAT rules. This is what I've configured:

[This example is based on a camera with a local IP address of 10.0.0.155]

Set up about 20 IP Host objects containing each of the network addresses the app scans with each IP object ending in .155

(e.g. Host1=215.44.23.155, Host2=192.168.100.155, host3 =3.44.5.155 etc) and add these objects to a Host Group

Set up NAT rule 1 to translate traffic coming from the camera to the app:
Type: DNAT
For traffic from: Camera local IP
Using Service: Specific ports used by the camera
Going to: Internet
Action, Change destination to: [My SSL-VPN User object] (this maps to my IP when I'm on the VPN)

Set up NAT rule 2 to translate traffic coming from the app to the camera:
Type: DNAT
For traffic from: [My SSL-VPN User object] (this maps to my IP when I'm on the VPN)
Using Service: Specific ports used by the camera
Going to: [IP host group containing the 20 IP addresses ending in .155]
Action, Change destination to: Camera local IP

For clarity, the last octet for each IP host is used to identify each camera and I duplicate this process for each camera I want to access

Screenshots attached for each type of NAT rule that is currently configured in UTM.

I've replicated the config to match the UTM but it just doesn't work.

Can anyone help?

Thanks

D

Example App to Camera NAT rule

Example corresponding Camera to App NAT rule



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

    Thanks for coming back to me.

    I'm not sure what you mean by 'what kind of IP'. The SSL VPN server is configured to issue addresses in the 10.81.0.128/25 space and I have statically assigned 10.81.0.129 to my user object.  Is that what you were asking?

Children
  • 0 in reply to DS7109

    The object, you are using, the SSLVPN object. What is in this object? Can you show us the IPs you are using there? 

    If those objects are all correct, check the packet capture of the firewall under diagnostic, if the NAT and firewall rules apply to the traffic or not. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I've configured the SSL VPN Server to assign static addresses and this is the VPN user object, configured with IP 10.81.0.129.

    The packet capture does show the NAT being applied, but there are also a lot of 'UNREPLIED' messages which I'm not sure about.

  • 0 in reply to DS7109

    And what objects are you using above? Can you show us the objects? 

    What can you see in the packet capture? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Apologies, forgive me but I don't understand what you mean by "And what objects are you using above?"

    The packet trace shows the app attempting to discover cameras on port UDP 5564 by walking the entire range on all IP's currently used by the phone. When it hits one of the addresses defined in the [YC 158_ VPN IPs] object (NAT rule 2 in the earlier screenshot) it immediately connects to the camera real IP on the same port, then further on a reply from the camera, and then the SFOS WAN IP connecting to the App (Seq 575 below, IP removed) Assume this is because the phone is connected to the VPN.

    The app then continues to walk the remaining IPs and hits another positive, from seq 822 below, and the same from the public IP again. (I've tried limiting the App-to-Cam NAT to only translate a single IP, 10.81.0.158, but made no difference other than the PCAP only shows it hitting one IP during the 'walk')

    Then there's a lot of noise that doesn't look relevant followed by the app attempting to stream from one of the cloud servers (streaming port is TCP 16305). I think the normal process here would be App > Cloud > Camera...Camera > Cloud > App. Since I'm blocking camera access to the internet, this won't work, and AFAIK the App then makes a P2P connection to the Camera IP address. I suspect this is where it's falling down as the app only tries to connect to the cloud on that port. (NAT'ing the cloud IP doesn't work as the camera sends a TCP reset immediately after the NAT has happened.) Also, the camera firmware and App version are the same as when this worked so I don't think anything's changed there.

    ...Head's spinning now having trawled PCAP after PCAP!!! I'm none-the-wiser as to why this worked on UTM but not SFOS.

    Could TLS decryption be a factor here? I think I've excluded the camera and the phone's VPN address (10.81.0.129) but as I'm still finding my feet with SFOS, I might not be doing it right. (Added a TLS rule with the source as the cam/dest Any - Don't Decrypt/Maximum Compatibility but I don't see any activity at all on the camera IP 10.0.0.158 in the TLS log)

    These are the lines in the PCAP file from the description above.

    562 2.641131 10.81.0.129 192.0.0.157 UDP 300 54929 → 5564 Len=256
    563 2.641167 10.81.0.129 192.0.0.158 UDP 300 54929 → 5564 Len=256
    ...
    574 2.660821 10.0.0.158 10.81.0.129 UDP 197 49168 → 5584 Len=153
    ...
    575 2.661034 x.x.x.x 10.81.0.129 UDP 197 49168 → 5584 Len=153
    ...
    822 3.506252 10.81.0.129 10.81.0.158 UDP 300 54929 → 5564 Len=256
    823 3.506508 10.81.0.129 10.0.0.158 UDP 300 22756 → 5564 Len=256
    826 3.530898 10.0.0.158 10.81.0.129 UDP 197 49169 → 5584 Len=153
    827 3.531117 x.x.x.x 10.81.0.129 UDP 197 49169 → 5584 Len=153
    ...
    927 3.926875 10.81.0.129 3.21.106.220 TCP 68 54388 → 16035 [ACK] Seq=1 Ack=1 Win=132096 Len=0 TSval=3730299526 TSecr=447288358
    928 3.926981 10.81.0.129 3.21.106.220 TCP 146 54388 → 16035 [PSH, ACK] Seq=1 Ack=1 Win=132096 Len=78 TSval=3730299538 TSecr=447288358

    Thanks for your help so far.

  • 0 in reply to DS7109

    So from what i can say, UTM and SFOS works the same in terms of your use case. You need to double check the actual object, that those matches your IPs of your Clients. 

    You should use the packet capture of the Webadmin to check, if the correct NAT and Firewall rule is applied. But if you see PSH/ACK packets, the connection is estabilished and works. 

    From the screenshot above, no hits are on the NAT outbound. There could be a mistake. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I'm not sure. It looks like the NAT is mostly working with one possible exception, explained below.

    To clarify the relevant IP's in these captures;
    10.0.0.158 = Camera real IP
    10.81.0.158 = Camera pseudo-ip used to trap the discovery process
    10.82.0.129 = My VPN address
    90.90.90.90 = My WAN address

    This is a tcpdump on the VPN IP address (10.81.0.129)

    890 4.289731 10.81.0.129 10.81.0.158 UDP 300 51441 → 5564 Len=256
    891 4.290034 10.81.0.129 10.0.0.158 UDP 300 51441 → 5564 Len=256
    892 4.310465 10.0.0.158 10.81.0.129 UDP 197 49320 → 5584 Len=153
    893 4.310724 90.90.90.90 10.81.0.129 UDP 197 49320 → 5584 Len=153
    ...
    901 4.452841 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49407 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    919 4.930364 18.218.23.115 10.81.0.129 TCP 76 [TCP Retransmission] 16035 → 49488 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1460 SACK_PERM TSval=2539240944 TSecr=17097097 WS=128
    972 7.452644 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49407 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    999 8.803963 10.81.0.129 18.218.23.115 TCP 68 49488 → 16035 [ACK] Seq=1 Ack=1 Win=132096 Len=0 TSval=17097298 TSecr=2539240194

    Which I read as:

    890: My VPN address > Pseudo camera address on UDP 5564 (Discovery port)
    891: NAT rewrites destination to Camera real address
    892: Camera responds on UDP 5584
    893: NAT rewrites source to WAN address on PortB
    ...
    901/972: This is where the camera tries to start streaming video to the VPN IP on port 16035
    919/999: I have no idea; It looks like the Chinese cloud server is trying to negotiate a stream with the app as well.

    I don't understand why line 893 rewrites to the WAN address, that should just go via a normal LAN>VPN path (I think?)

    The outbound NAT rule for the camera rewrites the destination of any internet IP with the VPN IP:
    [Source:10.0.0.158, Any Service, Destination: Internet]:[Keep original source, keep original service, rewrite destination with VPN IP]

    This is a tcpdump on the camera LAN IP address (10.0.0.155)

    All of the public IP addresses in this capture are the Chinese cloud servers. These are blocked by a firewall rule [IP Cam] >[Internet] (The camera has no internet access, but it didn't on UTM9 either)

    1 0.000000 10.0.0.158 3.137.220.229 TCP 60 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    2 0.000428 10.0.0.158 10.81.0.129 TCP 60 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    3 2.999879 10.0.0.158 3.137.220.229 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    4 3.000066 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    5 3.947414 10.81.0.129 10.0.0.158 UDP 300 51119 → 5564 Len=256
    6 3.970164 10.0.0.158 10.81.0.129 UDP 197 49318 → 5584 Len=153
    7 6.000991 10.0.0.158 3.137.220.229 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    8 6.001282 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49379 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    9 8.004239 10.0.0.158 35.227.140.194 TCP 60 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    10 8.004893 10.0.0.158 10.81.0.129 TCP 60 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    11 8.034876 10.0.0.158 3.137.220.229 TCP 60 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    12 8.035306 10.0.0.158 10.81.0.129 TCP 60 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    13 11.000074 10.0.0.158 35.227.140.194 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    14 11.000077 10.0.0.158 3.137.220.229 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    15 11.000314 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    16 11.000330 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    17 13.598131 10.81.0.129 10.0.0.158 UDP 300 62809 → 5564 Len=256
    18 13.630856 10.0.0.158 10.81.0.129 UDP 197 49319 → 5584 Len=153
    19 13.999839 10.0.0.158 3.137.220.229 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    20 14.000005 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    21 14.001203 10.0.0.158 35.227.140.194 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    22 14.001332 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    23 16.999525 10.0.0.158 3.137.220.229 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    24 16.999759 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49381 → 16035 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    25 17.000265 10.0.0.158 35.227.140.194 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    26 17.000382 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    27 19.999219 10.0.0.158 35.227.140.194 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
    28 19.999520 10.0.0.158 10.81.0.129 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 49380 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460

    This I read as being every attempt from the camera (10.0.0.158) to reach China cloud is rewritten to the VPN IP (10.81.0.129).

    So I think the only anomaly here is the attempt by the camera to reach the VPN IP being rewritten with the WAN address, but I'm not sure if that normal since the VPN network is technically on the WAN port. I don't know if the behaviour on lines 919/999 is normal or not, I think it probably is and likely happened when using UTM9 as well.

    What do you think?

Unfiltered HTML