Routing/access problem that just showed up with 7.401

Is 66.213.240.155 your primary firewall external interface, or an "additional" address, or ?

Barry

Try opening the DNAT definition and resaving it - another user reported that that solved a similar problem.  You might try the same with your masq rule.  Good question, Barry.

Cheers - Bob

Astaro's official response was, "any doesn't mean any when it comes from one of the internal address pools."

Which I cried baloney.

quote:

"The rule that you have in place is used to get around an issue with internal servers, when you are trying to access the public IP address of the server. This is a networking problem that goes along with DNAT technology in general. What happens is that the packets reach the ASG, which is set as the default gateway for the network.  The packet then is DNATed to the internal server. Now you have a packet with a source of the internal network and a destination of the internal network.  The server then uses ARP to transfer the data, thinking that the packet originated from the host on the LAN.  This is theoretically true, but then the session breaks down due to the asynchronous traffic pattern."

Uhm, ya. So any doesn't mean any if it comes from any internal network serviced by the firewall itself. Go figure.

It wasn't until I read your last post that I understood you were trying to access the DMZ server at the external IP.  Here's my understanding, and I welcome corrections...

It's not clear to me why, but, as I understand the documentation, this should work now without your full NAT if you are accessing the webserver via the HTTP proxy.

If your setup worked before outside the proxy, then I think that was an "unintended feature" of earlier versions.  Theoretically, the server in the DMZ would respond back to the Astaro, but the Astaro wouldn't know how to route the response, as support said in the quote you supplied.

One "standard" way to do that with Astaro is to SNAT, replacing the source 'Internal (Network)' with 'DMZ (Address)', but that defeats tracking Internal IPs by the webserver.  Your full NAT accomplishes the same thing as this SNAT.  Creating an Additional Address on the Internal interface and a DNAT from it to the webserver's DMZ address also should work, and would preserve the initiating IP - is that what you meant, Barry?

If you are accessing the server via the FQDN instead of the explicit IP, then a static DNS entry in the Astaro should solve the problem.

Another solution might be a route in the server or the Astaro.  Barry could tell us what that would look like if it would work.

Again, corrections of any misunderstandings are solicited.

Cheers - Bob

Yes, I'm running http proxy and trying to access our website from the internal network using the FQDN which resolves to our external internet addy.

His second response was more informative and I think probably clears this up a little better:

The any definition is truly any (0.0.0.0/0).  In the situation that I outlined before, the DNAT rule works properly as the traffic source is any and it does forward the packet accordingly.  The problem occurs with the return traffic - if the server has a route to the originating host via a route not containing the ASG.  The original client sends a syn packet to 

http://www.foo.com

 (1.1.1.1) and receives the syn/ack from 

http://www.foo.com

 (192.168.1.2).  The client then drops this packet and may send a rst packet as there is no known connection for 192.168.1.2.

If the packet is sent back to the ASG, the conntrack module in the backend will NAT the syn/ack packet back to 1.1.1.1 and forward it to the original client.  This is what the full NAT does, it makes sure that the return packet goes through the ASG.

So I think this probably should have never worked. So you have to run full NAT from all internally served IP networks, like the internal network and the vpn pool in order to access via the official external internet addy? This just seems a little strange.

Just to clarify my network a little. I'm using three network plugs on my ASG:

dmz -> 10.2.1.X
internal -> 10.2.2.X
internet -> our fancy inet addy's

and simply want the users on the internal leg of our network to be able to browse our ftpwebserver using our official FQDN. and subsequently our official internet addy's.

I have dnat setup for ANY HTTP ->  -> 

So for folks on the internal network the connection runs 10.2.2.X -> 10.2.2.1 (ASG's addy) ->  ->  and theoretically back again.

Is this making things clearer?

Hi there, 

Yes it i, but i still have a view questions.
Are the internal users use the HTTP proxy?
Do you use the proxy in Standard/Transparent/User Auth mode? 

I have a feeling what it could be, can you do me a favor and test if the setup works, if you disable the http proxy and your internal users surf directly through the DNAT to the DMZ?
please make sure that the webserver has set it's default route back to the ASG interface.

thanks Gert

http proxy is set to transparent, and yes the internal network is using it.

I'll play with the other settings as suggested and see what's up.

Hi,

i am just walking through the changes for 7.400 and 7.401 in regards of NAT. 
Do you use a Service or Network group object in DNAT/SNAT/FullNAT?

thx Gert

http proxy disabled, full nat disabled and it doesn't work. I was having problems with FTP also.

I'm not using any grouping with dnat/nat

now that is strange, i didn't expect this.

I think i can better help you, if you send me a Confid-Dump package. 
You get that in WebAdmin > Support > Advanced > Confid Dump. 

It includes, low-level nat and filter rules, as well as routing and interface configuration. That should be enough to understand what goes wrong. 
You can send me that via Email.

thanks
Gert

I look forward to learning what Gert has seen here.  In the meantime, it seems like the easiest thing to do would be to get rid of the full NAT and just add a static DNS entry to the Astaro that associates the FQDN of the ftpwebserver to its 10.2.1.x address.

Cheers - Bob
PS I'm confused by Gert's implication that a DNAT for traffic 'Any -> HTTP -> [External IP for server]' to '[Private IP for server]' would work with traffic from 'Internal (Network)'.

I look forward to learning what Gert has seen here.  In the meantime, it seems like the easiest thing to do would be to get rid of the full NAT and just add a static DNS entry to the Astaro that associates the FQDN of the ftpwebserver to its 10.2.1.x address.

Cheers - Bob
PS I'm confused by Gert's implication that a DNAT for traffic 'Any -> HTTP -> [External IP for server]' to '[Private IP for server]' would work with traffic from 'Internal (Network)'.