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 Suggested Answer
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 300 views
  • Users 0 members are here
Options
Suggested

Sophos XGS: DNAT Through Routed VPN

FMXio

Hello everyone,

I am attempting to redirect all requests made to 192.168.10.5 to 172.16.10.5. The VPN is working properly on both sides.

Sophos XGS: DNAT Through Routed VPN

Details:

#VPN Working 100%
LOCAL-LAN: 192.168.10.0/24 (Sophos)
REMOTE-LAN: 172.16.10.0/24 (pfSense)

#Servers
Old Server: 192.168.10.5
New Server: 172.16.10.5

I've set up a DNAT rule as follows:

Source: 192.168.10.0/24
Original Destination: 192.168.10.5
Translated Source: Original
Translated Destination: 172.16.10.5

I've also tried adding a DNAT rule via the console, both independently and in conjunction with the above rule, but with no success:

set advanced-firewall sys-traffic-nat add destination 172.16.10.5 snatip 192.168.10.5



Added TAGs
[edited by: Raphael Alganes at 3:47 PM (GMT -8) on 13 Nov 2024]
Parents
  • 0

    Hello,

    you are trying to reach a server at 192.168.10.5 /24 from the local LAN with 192.168.10.0 /24.

    This traffic will never hit the router (= gateway), because that traffic is inside your LAN and will stay there, no need to involve the gateway.

    So basically, you can configure very sophisticated rules and settings at the Sophos XGS, but that won't work.

    Are you trying to avoid changing the Server-IP at the clients?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

Reply
  • 0

    Hello,

    you are trying to reach a server at 192.168.10.5 /24 from the local LAN with 192.168.10.0 /24.

    This traffic will never hit the router (= gateway), because that traffic is inside your LAN and will stay there, no need to involve the gateway.

    So basically, you can configure very sophisticated rules and settings at the Sophos XGS, but that won't work.

    Are you trying to avoid changing the Server-IP at the clients?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

Children
  • 0 in reply to PhilippRusch

    Thanks for your input, Philipp! Actually, I'm trying to redirect all the requests made from 192.168.10.0/24 to a server at 192.168.10.5 (Local-IPSec VPN) to another server (via IPSec VPN) at 172.16.10.5.

  • 0 in reply to FMXio

    True, i missed this: 

    Maybe PFsense is solving this differently, but what you have here is: 
    As there is no device to answer to this IP in your network, SFOS will also not do an ARP for it. 
    The client will reach out with an ARP to look for 192.168.10.5 - But SFOS is not responsible for it - So it will not answer and the SYN Paket will never be send. 

    You can workaround this by putting the ALIAS IP of 192.168.10.5 on the LAN interface of the SFOS Firewall. Therefore we will reply to the ARP and then the connection will be routed. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    THAT sounds like a solution - good point!

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to LuCar Toni

    Hey, I confess I thought about it, but with so many ideas at the same time, this one just disappeared. Now, after setting up this alias, the regular DNAT on the GUI interface is registering logs. That rule in the console, 'set advanced-firewall sys-traffic-nat add destination 172.16.10.5 snatip 192.168.10.5', didn't work. Thanks!!!! I'll keep finding a solution, and now I can capture packets and think better...

Unfiltered HTML