HTTP-Server not reachable. Possible problems due to update to 7.306 -> 7.401 ?

It's not clear to me why you would need a policy route.  Everywhere we have a webserver published, simple DNATs solve the problem:

Traffic Source:  Any
Traffic Service: HTTP
Traffic Destination: [FIBER (Address)] 

NAT mode: DNAT (Destination)

Destination: [webserver] 
Destination Service: [leave blank]

As long as the gateway for the webserver is the IP of 'Internal (Address)', then no further routing should be necessary.  I realize that I didn't answer your question directly, so I apologize if I've misunderstood something.

Cheers - Bob

We have a DNAT rule.
Traffic Source: any
Traffic Service: HTTP
Traffic Destination: FIBER (Additional IP 38)
Destination: HTTP-Server
Destination Service: HTTP

If we only had that rule in place it didn't work because HTTP-Server would receive the incoming packets (source FIBER connection) and try to transmit the answer to his DEFAULT GW the ASVG320 which would answer the webclient over the DSL connection since this was the default route for that for the ASVG320 to that WEB-client. Thats why we had the rule in place so traffic (80 -> 65535) orignating from the HTTP-server would go over the FIBER connection instead of the DSL.

I'll explain what we need i just want it work so if there is a simpler way great [:)] Perhaps we approached this totally wrong.

Connections:
DSL is configured as "Cable Modem (DHCP)" DEFAULT GW
FIBER is configured as "PPPOE" (with a block of 5 IP's which are configured as additional addresses) (i see a made a mistake in the first post this is not a DSL connection, i don't think it really matters though)

The network which the HTTP server is located in has a masquerading rule like this:
DMZ -> interface: FIBER

We want to publish a HTTP server to the world on 1 of the additional addresses of the FIBER connection and if i only use the DNAT rule it didn't work.

I'm stumped how to solve this [:S]

We have a DNAT rule.
Traffic Source: any
Traffic Service: HTTP
Traffic Destination: FIBER (Additional IP 38)
Destination: HTTP-Server
Destination Service: HTTP

If we only had that rule in place it didn't work because HTTP-Server would receive the incoming packets (source FIBER connection) and try to transmit the answer to his DEFAULT GW the ASVG320 which would answer the webclient over the DSL connection since this was the default route for that for the ASVG320 to that WEB-client. Thats why we had the rule in place so traffic (80 -> 65535) orignating from the HTTP-server would go over the FIBER connection instead of the DSL.

I'll explain what we need i just want it work so if there is a simpler way great [:)] Perhaps we approached this totally wrong.

Connections:
DSL is configured as "Cable Modem (DHCP)" DEFAULT GW
FIBER is configured as "PPPOE" (with a block of 5 IP's which are configured as additional addresses) (i see a made a mistake in the first post this is not a DSL connection, i don't think it really matters though)

The network which the HTTP server is located in has a masquerading rule like this:
DMZ -> interface: FIBER

We want to publish a HTTP server to the world on 1 of the additional addresses of the FIBER connection and if i only use the DNAT rule it didn't work.

I'm stumped how to solve this [:S]

I'm sorry, I didn't read closely enough.  You are doing it exactly the "standard" way; without a route in the Astaro or the webserver, the webserver's responses can't get to the FIBER connection.

If you have Astaro support, I would submit a ticket if I had this problem.

Did the problem begin immediately with the 7.400 upgrade, or with the 7.401 Up2Date?  I'm sure you've tried rebooting, so I'm stumped, too.

I don't know if you can restore a 7.306 backup onto a unit running 7.401.  Can anyone else comment on that?

If this just broke with 7.401 then this may be very similar to the problem we where having routing from our internal network to the DMZ. If you put in a full NAT routing this may fix the problem. Take quick peek and possibly try this out:

http://portal.knowledgebase.net/disp...asp?aid=215522

or KB article 215522. Basically they suggest full NAT routing just to make sure the firewall doesn't get confused. I know this sounds not quite the same but it's certainly worth a shot.

I think there may be something wrong with dnat in 7.401 if all the sudden all these dnat rules are getting whiped out.

My guess is that the DNAT is working correctly, but that, for some reason, the firewall isn't doing connecetion tracking correctly and the reponse is lost.

It certainly would be interesting if Massdriel could put a sniffer in the network to see if the message gets to the server and back to the Astaro, as I'm guessing it does.  In that case, a full NAT like you did would indeed solve the problem of providing a route.  But I don't think the fact that it solves the problem is proof of anything.

Cheers - Bob

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

Barry

My guess is that the DNAT is working correctly, but that, for some reason, the firewall isn't doing connecetion tracking correctly and the reponse is lost... But I don't think the fact that [full NAT] solves the problem is proof of anything.

I'll agree with you there. The KB was written in the 7.1 timeframe. It simply gets you back up and running so that your own people can view your own website instead of it being completely inaccessable by forcing the routing. Figuring what the firewall is throwing away is a whole 'nother story.

Hi,

Well I've gotten back from the eastern holidays and for no apparent reason it works and all outside IP's are pingable again.

I suppose this could have been an ISP issue which was weird though because this is a quite expensive line and outgoing traffic was possible, normal client -> server traffic. So didn't think the problem was there or contact them and i just gotten the new firmware update of Astaro.

I also traced back that the Google spider was able to contact the HTTP server with 7.400 installed and it works now w/o any change at all on 7.401 same config when i started this thread.

So i suppose this was an ISP issue, if it returns I'll look into this both sides and find the culprit.

Anyhow I'm glad it works again and I'll monitor this server uptime for this service.

Regards,
Maasdriel

I had a problem yesterday where it seemed like my DNATs weren't working, but it turned out that my dyndns IP was messed up.

Barry

So, does everyone agree that this wasn't an Astaro DNAT problem in any of the cases here?

Cheers - Bob