Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 4 replies
  • Subscribers 0 subscribers
  • Views 1116 views
  • Users 0 members are here
Options
Suggested

Odd dnat/snat behavior

grgcombs
I'm seeing some odd behavior again in 6.908, that I was able to fix in 5.x regarding dnat/snat.

I've got all my internal network masquerading to [ex.ter.nal.1]

I've got a server in my internal network [192.168.0.5] snat'ed for any service to any destination as [ex.ter.nal.22]

I've got that same server in my internal network dnat'ed such that any traffic on any port coming in to [ex.ter.nal.22] has the destination changed to [192.168.0.5]

[ex.ter.nal.22] should equal [192.168.0.5] in every respect.  This works fine when looking at that external address from outside the firewall.  From inside the internal network (say 192.168.0.7) I can successfully ping [ex.ter.nal.22], but any attempts to connect to services from inside the network to that external address fail with timeouts.  Nothing shows up in the packet filter during this time, so that's not it (I've always made allowances for the services in question).

This was previously remedied with a dnat translation in 5.x to point anything from the internal network going to that external address over to the internal address 192.168.0.5 ... even though this is technically covered in the dnat above, I've added it anyway in an attempt to fix this problem, to no avail.  I've also previously employed multiple dns servers, inside and outside the network and I definitely don't want to go this route again.

Any suggestions?

Aside from this, this beta is working really well for me.  I love the new webadmin interface.  VPN PPTP is flawless for me.  I look forward to instructions in implementing VPN SSL.

Greg
Parents
  • 0
    I don't really understand what you are trying to do, it looks overly complicated to me?

    Do you have 2 external interfaces?

    Why don't you route the internal traffic to your server within the firewall?

    Ian M[:S]
  • 0 in reply to RFCat_vk_01
    I do, but I'll give you an example of why this is a hassle (and how I fixed it in a moment):

    We've got laptops that at times exist inside and outside of the network, as folks take them home or bring them back to work.  In setting up their email, we need to have a consistent setting so that the email server's domain name doesn't have to change whenever they take their laptop home.  Or the company's website is available both inside and outside the firewall at the same domain name.  We want to avoid having to set up two dns servers where one routes the same domain name to both the proper external ip address and the other to the server's internal ip address ... www.xyz.com should work for wherever you're hitting it from, whether it's inside the firewall or outside.  This problem always seems to manifest itself whenver you've got a publicly accessible server behind a firewall with nat'ing.  The external ip address isn't accessible from inside the firewall, and therefore the  real domain name doesn't work from inside the firewall either.

    Maybe I'm being too obtuse in my explanations.  In any case, I've found the solution for V7.

    Create a Full Nat:

    Traffic Source = Firewall's Internal Network (192.168.0.0/24)
    Traffic Service = Any
    Traffic Destination = Server's External (WAN) IP Address

    Change Destination to = Server's Internal (LAN) IP Address
    Change Source to = Firewall's Internal Address (192.168.0.1/32)

    The key that I was missing was the difference between the LAN's internal network and the firwall's internal address.
  • 0 in reply to grgcombs
    somehow, I think there has to be a more efficient way to do what you want. but I am not a pro, so I couldnt tell ya.  one way may be to intercept internal requests which point to the external domain and route accordingly... but again, I am no pro.
  • 0 in reply to BanksDad
    In v7 you shouldn't need that full nat rule at all. I just tested it, and I can connect to my internal web server, even on a public alias address, using only a standard dnat rule like:

    Source: Any
    Service: HTTP
    Destination: External[Alias](Address) or External(Address)
    Change Destination: InternalIPDefinition

    In v6 you needed to add an SNAT rule, because local clients connecting to an external address on the Astaro from an internal client, but the replies would come directly from the internal webserver. By snatting those connection attempts, the reply traffic would go back through the Astaro, and the client would be able to connect. V7 appears to do this automatically.

    Also, you can use static DNS entries in v7 in place of installing an entire DNS server. It would be better to setup a static dns entry, and direct clients to connect directly to the internal server, than it would to 'bounce' traffic off the astaro unnecessarily.
Reply
  • 0 in reply to BanksDad
    In v7 you shouldn't need that full nat rule at all. I just tested it, and I can connect to my internal web server, even on a public alias address, using only a standard dnat rule like:

    Source: Any
    Service: HTTP
    Destination: External[Alias](Address) or External(Address)
    Change Destination: InternalIPDefinition

    In v6 you needed to add an SNAT rule, because local clients connecting to an external address on the Astaro from an internal client, but the replies would come directly from the internal webserver. By snatting those connection attempts, the reply traffic would go back through the Astaro, and the client would be able to connect. V7 appears to do this automatically.

    Also, you can use static DNS entries in v7 in place of installing an entire DNS server. It would be better to setup a static dns entry, and direct clients to connect directly to the internal server, than it would to 'bounce' traffic off the astaro unnecessarily.
Children
No Data
Unfiltered HTML