Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 3 subscribers
  • Views 13049 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

Loopback NAT or Nat-on-a-stick question

ElizabethGreene
Hi.

I would like to be able to access our internal servers by the external ip from within the network.  Is this possible with an Astaro firewall?

As an example.  GlobalOptions resolves to a public IP 208.66.47.50.  That is protected by the astaro box.  A user, also protected by the astaro, cannot connect to that public IP.  


Cisco calls this "Nat on a stick"
Network Address Translation on a Stick [IP Addressing Services] - Cisco Systems

Normally I would make this netfilter rule, but I'm not sure how to do it via the web interface.

-A POSTROUTING -s 192.168.0.0/255.255.255.0 -d 192.168.0.0/255.255.255.0 -j SNAT --to-source 192.168.0.1

Thanks in advance,
-ellie


This thread was automatically locked due to age.
Parents
  • 0
    Could you setup a static entry for Global Options in the Network | DNS mapping section?
  • 0 in reply to eganders_01
    I had considered setting up split dns, but there are a lot of hosts* so it wouldn't be an great solution**.  

    * We host web based applications.
    **and we're using MS DNS servers which don't support Bind-style split dns.  Double PITA.
  • 0 in reply to ElizabethGreene
    Elizabeth, I'm not very good with Cisco, but I wonder if your rule wouldn't simply make internal traffic appear to be coming from the Cisco device.  If that is indeed your goal, then you can duplicate that with a SNAT rule in the Astaro:

    Traffic Source: Internal (Network)
    Traffic Service: {not sure, 'Web Surfing' or 'HTTP'?}
    Traffic Destination: {You might have defined a group or subnet of webservers}
    NAT Mode: SNAT
    Source: Internal (Address) {or just 192.168.0.1}
    Service: {leave this blank!}



    You might need to set up a packet filter rule depending on what you have already.  The downside of this solution is that you can no longer see the specific origin of internal traffic with the webservers - everything is with 192.168.0.1.

    Having said that, I feel like my suggestion above is a bandaid instead of the "right" solution.  I suspect you have DNAT rules for your webservers and that you could create a policy route for internal traffic to the group of servers.  The most time-consuming part of that would be creating the group of webservers if they aren't already all on a separate subnet.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Thanks Bob, I think that is a step in the right direction.

    Your assessment "simply make internal traffic appear to be coming from the Cisco device" is correct.  That is exactly what it does.  Internal traffic accessed by the external IP has the source IP rewritten to the firewall's address.

    Our current band-aid solution is to use full nat that translation rules for everything, with the fw internal IP set as the source address.  This works, but all traffic appears to come from the FW now.  This is "not so great" for both security and web-statistics purposes.

    -ellie
  • 0 in reply to BAlfson
    Elizabeth, I'm not very good with Cisco, but I wonder if your rule wouldn't simply make internal traffic appear to be coming from the Cisco device.  If that is indeed your goal, then you can duplicate that with a SNAT rule in the Astaro:

    Traffic Source: Internal (Network)
    Traffic Service: {not sure, 'Web Surfing' or 'HTTP'?}
    Traffic Destination: {You might have defined a group or subnet of webservers}
    NAT Mode: SNAT
    Source: Internal (Address) {or just 192.168.0.1}
    Service: {leave this blank!}



    You might need to set up a packet filter rule depending on what you have already.  The downside of this solution is that you can no longer see the specific origin of internal traffic with the webservers - everything is with 192.168.0.1.

    Having said that, I feel like my suggestion above is a bandaid instead of the "right" solution.  I suspect you have DNAT rules for your webservers and that you could create a policy route for internal traffic to the group of servers.  The most time-consuming part of that would be creating the group of webservers if they aren't already all on a separate subnet.

    Cheers - Bob


    Split DNS on Windows 2003 server is really not that difficult.  Here is a link that describes the needed configuration.

    Configure a split DNS system on Windows Server 2003

    I don't know if that is what you may need, but that is how split DNS is done in AD.
  • 0 in reply to BAlfson

    I just added an "additional hostname" to the existing internal host definition. For example: map01.internal.<myorg>.com can also be accessed as map.stage.<myorg>.com from behind the Sophos (internal) but is still publicly accessible from the outside via the DNAT and public DNS A record. This won't help you validate your DNAT from inside but provides what is needed for host headers and such. Full NAT would work too but prefer not to use that for something this simple where we don't really care what the actual IP resolves to.

Reply
  • 0 in reply to BAlfson

    I just added an "additional hostname" to the existing internal host definition. For example: map01.internal.<myorg>.com can also be accessed as map.stage.<myorg>.com from behind the Sophos (internal) but is still publicly accessible from the outside via the DNAT and public DNS A record. This won't help you validate your DNAT from inside but provides what is needed for host headers and such. Full NAT would work too but prefer not to use that for something this simple where we don't really care what the actual IP resolves to.

Children
No Data
Unfiltered HTML