Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 3144 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.
Parents
  • 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.
Reply
  • 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.
Children
  • 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?