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

Again Local nat bug - Help please!

Spider
First versions of new version 5 had a known problem with local NAT issue. I still, with latest update 5.016, have the problem. 
I began with one packet rule and one nat rule, http service. If I try to brows the server with external nat address from outside the LAN this works fine, but not from inside the LAN. This works fine with ver 4.xxx.

Any ideas????


This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to dhofmann1
    Hi dhofmann1,
    One 'simple' question: Why my nat rules works just fine in ver 4.x and same rules imported in ver 5.x does not?
    Regarding your tip to look at Tims solution: Is his solution right, or is that just workarourd som Astato problem?

    Regards,
    Zeraldin
Children
  • 0 in reply to Spider
    I agree, I also had this working in ASL4 (still do at a site) and a raw IPTables Linux firewall, so I know that with NAT you can do this, there is no question about that. Do you have the HTTP proxy turned on? If so, as a test turn it off temporarily and then see if it works. I believe I tried this and I was then able to access local servers using public IP's. I have an idea that it is the HTTP proxy not taking into account the NAT rule. The only work around I have came up with is to add in the /etc/hosts file a record that points www.mydomain.com to the internal private IP. Because the HTTP proxy looks here first before querying DNS it will then go straight to the internal server.
  • 0 in reply to Brent_Gay
    hi guys, 

    one quick question, 
    is the HTTP server you want to access on the same LAN or is it in the DMZ?

    Gert
  • 0 in reply to Spider
    ok before this gets turned into something that this is not
    this issue concerns the specific situation 1 external ip 1 internal subnet server on same subnet as client
    thats it
    the workarounds are as follows
    hosts
    internal dns
    source translation
    dmz with different subnet
    using a different external address for mapping
    using the internal ip directly
    using the computer or devices internal name (broadcast wins whatever)
    as in the thread that me and timber 666 were involved in
    strange nat configurations that are not correct

    timber trid this
    Hi,
    this is the NAT-configuration (eth0=internal nic - eth1=ISP)
    Chain USR_POST (1 references)
    pkts bytes target prot opt in out source destination 
    0 0 MASQUERADE all -- * eth0 192.168.100.0/24 0.0.0.0/0 
    6 288 MASQUERADE all -- * eth1 192.168.100.0/24 0.0.0.0/0 

    I don't know for sure, but i guess by adding the first nat-rule all packets (the second one in my earlier post) the packets coming from an internal IP now get a new source ip: the ip of the internal nic of my astaro. When the destination ip is outside the network the packets are send through the ISP Nic, if not packets are sent to my internal webserver and this server is sending the replies directly to the clientpc on my internal network... this is just a guess, but the 'solution' is working fine without any issues so far... 
    Tim. 
    ron f tried this

    I changed the rule slightly.

    Instead of saying From ANY TO: External Interface I say
    from Internal Network To External Interface.

    The logging issue doesn't bother me for my home network.


    one of the side effects is that all packets get translated to 
    different addresses so it works
    but logging stops working correctly
  • 0 in reply to Gert Hansen
    Gert,
        The web server is on the same LAN as the client.

    I tried this again when I got home....and it works without any hitches.

    Here the different scenarios I tested:

    Constants:
    ASL 5.016
    1 external interface and 1 internal interface...no DMZ, no aliases, just 1 dynamic IP
    normal MASQ rule for internal LAN
    normal DNAT rule for web server
    No additional record in /etc/hosts file
    www.mydomain.com resolves to the external interface of the ASL on the client and from the ASL

    When using transparent HTTP proxy:
    I did not have to add any 'special' NAT rules, and it just worked

    When not using the Proxy:
    In order for me to be able to access my webserver using the public DNS name I had to add the following 'special' NAT rule

    Internal (Network) -> External (Address) / HTTP   Internal (Address)   WWW_SERVER

    After adding that NAT rule I can access the server. This is the same NAT rule I had to use in ASL4.

    Sorry for my previous post...When I was troubleshooting before, it must of been with an earlier release??