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

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

Maasdriel
Greetings,

We had published a HTTP server on our FIBER connection to the world. We were able to ping the IP's on the FIBER connection from the outside, now we can not (none on the 5 IP's). We are not able to connect to our webserver (from outside) through our FIBER connection (which is NOT our DEFAULT GW).

We have a 2 ASVG320 in failover mode.
We have 1 typical DSL for our internet traffic (DSL) and 1 FIBER connection  for services that demand better latency/bandwidth.

DSL is configured as "Cable Modem (DHCP)"
FIBER is configured as "DSL (PPPOE)"
DSL is our DEFAULT GW.

We had a policy route to be able to route back to the world over the correct interface. Like shown below:
Source Network: HTTP-Server
Service: HTTP Reverse (80 -> 65535)
Destination: Any
Gateway: FIBER-GW

Are there any changes made in this update which could have effect on the situation above ?

Best regards Maasdriel


This thread was automatically locked due to age.
Parents
  • 0
    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
  • 0 in reply to BAlfson
    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]
  • 0 in reply to Maasdriel
    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?
  • 0 in reply to BAlfson
    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.
  • 0 in reply to predatorsw
    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
Reply Children
No Data