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

Full NAT Problem

TeBear77
So I have an internal server that uses a different default gateway.  After searching the forums a bit I found a post by Mr. Daniel on that if the device inside the network is not using the astaro as the default gateway then you will need to setup a full nat. The goal here is to allow access to the EOS server from my SECONDARY ATT line  (Note it is the secondary)  72.16.125.45 external address.  Can you please let me know where/what I might be missing.

See attached Visio for visual reference.


In my Nat rules this is what I have made:

Traffic Source -> Any
Traffic Service -> Any (did any for testing to see if I could touch the server)
Traffic Destination -> External 2 Second IP Address (72.16.125.45)

Nat Mode: Full Nat

Destination -> EOS1 (10.4.11.1)
Destination Service -> blank

Source Internal secondary IP (10.10.1.2)
Source Service -> blank

Log inital -> yes

Automatic Packet filter rule -> no

Packet filter rule

Position -> 12

Source -> Any
Service -> Any
Destination -> EOS1
Action -> Allow
Time event -> Always
Log traffic -> Yes


This thread was automatically locked due to age.
  • 0
    That looks like you have the theory right, but finding blocked packets in the Packet Filter log would indicate that you have the following problem:

    Traffic Destination -> External 2 Second IP Address (72.16.125.45)

    needs to use the actual interface object created by WebAdmin, not a Host definition with the same IP

    Traffic Destination: External [EOS1] (Address)



    Was that the problem?

    Cheers - Bob
  • 0 in reply to BAlfson
    Bob not sure if I understand what your saying... I want to use my additional external IP 72.16.125.45 on my secondary Internet connection to punch a hole to allow access to this server from the inet.

    So anyone on the internet will use 72.16.125.45 to get to this web server, in turn the astaro is making 10.4.11.1 on the internal appear to be the 72.16.125.45.

    Most likely we will need a static route stating that if it is coming from the EOS server that it needs to go out the secondary internet interface.
  • 0
    It is possible as well to change the default gateway of the EOS server... which i have tested and still haven't had the result I was looking for ... I see no dropped traffic to or from the 10.4.11.1 address
  • 0
    The route shouldn't be necessary, although one in the device that's the current gateway with a DNAT rule in the Astaro is another solution instead of the Full NAT.  Please show a picture of your NAT rule.

    Of course, the most straightforward solution would be to just use a DNAT in the Astaro and have the Astaro as the DG for the EOS server.  Whetther a DNAT or a Full NAT, the target for the traffic comming in must be the (address) object created by WebAdmin, not a Host Definition with the same IP.

    Cheers - Bob
  • 0 in reply to BAlfson
    I have changed the default gateway on the EOS server to 10.10.1.1 Note the the screen shot is a DNAT
  • 0
    That looks perfect.  Is there a Packet Filter Drop rule above your allow rule?  If not, is there anything in the Intrusion Prevention log?

    Cheers - Bob
  • 0 in reply to BAlfson
    Moved the EOS rules to the top to test and still no dice
  • 0
    my question about the routing is that the Astaro's GW is set for External1 not External2 when the traffic is coming back from the EOS server is Astaro sending it out External1 while the client is waiting for traffic on External2?

    Or should the DNAT rule be handling those requests?

    Nothing in the IPS logs
  • 0
    Since the Astaro is a "stateful" firewall, the 'QOS -> Any -> Any : Allow' rule should not be necessary for handling the server's responses.  This "statefulness" is done by "connection tracking" that remembers where a packet came from, so, if the response from the EOS server gets back to the Astaro, I'm pretty sure it should know what to do with it, so, yes, in a way, what makes DNAT work should get the response traffic back out the right interface.

    I'm obviously not asking the right question though.  This may seem a bit random, but what happens if you temporarily disable the DMZ interface?

    Cheers - Bob
    PS TeBear77 sent me his Packet Filter log, and it proves that the traffic arriving at the IP does get forwarded to the correct internal IP.  With the Astaro now as the default gateway for the EOS server, there must be somthing else going on in his network that's preventing the response from getting back to the Astaro.
  • 0 in reply to BAlfson
    To reply back I did get the issue resolved in creating a 

    Static Routing > Policy Route 

    Position -> 1
    Route Type -> Interface route
    Source Interface -> Internal
    Source Network -> EOS server (10.4.11.1)
    Service -> Any
    Destination Network -> Internet
    Target Interface -> External2

    Thank you Bob for all your help.

    Though why doesn't the "stateful" remember to route the traffic back out the External2 interface?