Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 37 subscribers
  • Views 1272 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

How to best make a machine reachable over a VPN / Portforwarding over VPN (FULLNAT/DNAT+SNAT)

Christoph Müller

Good morning,

I have hecked the forum(s) for old post about this and found something similar in this Post https://community.sophos.com/products/unified-threat-management/f/german-forum/59797/portforwarding-durch-ein-vpn-zur-anderen-seite-moglich

My issue is with a machine that is a hardware security appliance on site B.

Sites A and B have 1 UTM each, and are connected via IPsec VPN.

Unit (Site) A has a dedicated additional address for this construct over which we want to let the appliance on site B talk to the WAN.
It should also be reachable from external WAN on the dedication addition address with specific ports that I have grouped together.

I have configured a FULLNAT on UTM A with the following details:

Traffic Selector (source): Any
Target Service: SecurityAppliance portgroup
Target Address: Dedicated Additional Address (x.x.x.51)
Source Translation: x.x.x.51
Destination Translation: Appliance IP on site B
No Service Translation.
Automatic firewall rules are on.

According to every post I read about something similar this should work. But it doesn't.
Now I think I might have some routing issue or something because in the firewall log from site B I don't have any (default) blocks relating to this.
Do I have to edit the VPN between sites for this?

I figured it would be easy enough to complete this configuration but not seeing any dropped packets makes me doubt this particular configuration a little and makes diagnostics a pain.

Anyone got any ideas?

 

Thanks in advance

~Chris



This thread was automatically locked due to age.
Parents
  • +1

    Hey Bob,

     

    I seem to have located the issue in the VPN connection.

    Due to the fact, that the customer was trying to get a public IP through the VPN tunnel, we got nowhere since the tunnel was only configured for the internal interfaces.

    We changed the DULLNAT a little.

    Now instead of the public additional address we use the Internal LAN Interface as source.

    Since the tunnel has configured that network, the packages are routec correctly.

    Here is the FULLNAT configuration

    Traffic Selector (source): Any
    Target Service: SecurityAppliance portgroup (http, TCP/UDP10000)
    Target Address: Dedicated Additional Address (x.x.x.51)
    Source Translation: Internal LAN Interface IP 172.16.0.1
    Destination Translation: Appliance IP on site B
    No Service Translation.
    Automatic firewall rules are on.

    Still in the testing phase but this looks like working.

     

    Regards

    ~Chris

  • 0 in reply to Christoph Müller

    The public IP could have worked, Chris, if it had been added to the tunnel and the Remote Gateway was set as "Initiate Connection."

    That was part of the reason I asked for the picture - to determine if the .51 in each spot was the same object.  It's why I recommend obfuscating 58.68.78.88 as 58.x.y.88, 10.33.1.99 as 10.x.y.99, 172.16.0.1 as 172.16.x.1 and 192.168.0.1 as 192.168.x.1 - to make it clear what's public and what's private.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to Christoph Müller

    The public IP could have worked, Chris, if it had been added to the tunnel and the Remote Gateway was set as "Initiate Connection."

    That was part of the reason I asked for the picture - to determine if the .51 in each spot was the same object.  It's why I recommend obfuscating 58.68.78.88 as 58.x.y.88, 10.33.1.99 as 10.x.y.99, 172.16.0.1 as 172.16.x.1 and 192.168.0.1 as 192.168.x.1 - to make it clear what's public and what's private.

    Cheers - Bob

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

    Morning Bob,

    Thanks for elaborating on that point.

    From what I see in the firewall and from your explanation I completely concur.

    The issue we had was more of a visibility thing (at least I guess you could call it that best). Since we had no visible blocks in the firewall Log I was not seeing where the problem originated but logic wise we assumed that it was the interface /public IP missing from that VPN tunnel.

    Would probably not have changed much if we knew it right away though. The tunnel is rather critical for the customer since they are monitoring hazardous stuff over it and we really don't want downtimes on that. Would be way too much hoops to jump through just for a change in the tunnel when you can just change the source mapping.

    Anyway, thanks again Bob, really appreciate your work on here.

    Cheers
    ~ Chris

Unfiltered HTML