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

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

It's an "additional," primary is .154

A re-save of dnat and masq didn't seem to improve things. It's like dnat isn't working for the 10.2.2.X internal addy's. I'll add a specific dnat from internal to the webserver and see if that helps.

I put in a specific dnat rule internal network 10.2.2.0/24, http to 66.213.240.155 to go to 10.2.1.80 and it still doesn't like it. Sounds like we may have an official bug on our hands? It seems a little strange as the dnat rule from our external ip addy to the ftpwebserver appears to work.

If you have support, you should probably open a case.

You could run tcpdump on both the ext and int interfaces, and see if the packets are getting routed correctly in each direction.

Barry

tcpdump? Is there a way to do that from the UI? I tend to avoid the command prompt.

Sorry, command-line only.

You could use Wireshark on a PC, but you'd have to put a hub or tap or span-port on each side of the firewall to get the full picture.

The Wireshark and Pcap folks have a new remote sniffer interface, which would be great for this case, but it's not going to be trivial to get running.

Barry

http://portal.knowledgebase.net/display/2/articleDirect/index.asp?aid=215522

This seems silly to me. Wouldn't a plain old dnat any http ip destination -> webserver work? I added in a full NAT as suggested here and it seemed to work.

That was article ID 215522, the help system while trying to help you sticks in a ton of other junk in the url.

Yes, DNAT should work. I use it as do many others here.

Barry

This sounds similar to https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39170

Barry

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