Guest User!

You are not Sophos Staff.

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

Additional Interface not pingable when it says up in WebGUI (DNAT)

Hello,

I've recently come across a problem that in my eyes makes no sense, I have been trying to get DNAT to work with a new DMZ server.

We have an additional server in the DMZ already, fully functioning. I've tried copying every single rule and configuration from that one, however it is not that simple.

I first created the additional interface which will be the external IP-address of the server. (x.x.x.x/32).

Secondly, I created DNAT for the DMZ: Any->Port 80->External-IP of Additional Interface -> Change to: internal private IP of DMZ-server -> same port number as in first step (80).

 

When trying to access this IP using any webbrowser, it returns no answer, nothing at all.

I can ping the external IP-address of the physical external interface, but not the additional interface that I created for the DMZ public IP.

 

According to the WebGUI, the additional interface and the physical interface itself are up and running.

 

Hopefully you can help me resolve this :)

 

Best regards,

Eric

 



This thread was automatically locked due to age.
Parents Reply Children
  • The first picture shows the DNAT configuration and the second is the additional interfaces created.

    In the second picture I show the other additional interface used for our other DMZ server which is fully functioning and ends with .5

    .7 is the new server which shows as up but cannot be pinged or connected to.

  • Hi Eric,

    Configure DNAT as shown in the screenshot. Remove the change the service to HTTP in Action.

    In the additional address configuration, configure the ISP provided subnet mask on the additional address in place of 32.

    Hope that helps.

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • Thanks for the reply!

     

    It helped with the ping issue, although I still cannot connect to the HTTP server.

    When using Nmap it says that that port is filtered.

     

    The firewall automatically created a rule for traffic using that port to the servers on the inside, so nothing is blocking it.

    No previous rules are blocking it either, I also tried creating a rule for anything using that port going to the outside port, this did not help either.

     

    What could be filtering me from connecting?

     

    EDIT: Looking at the logs, it says Default DROP is the reason for this action, even though there are rules that allow this port and IP, Hmm...

  • Hi Eric,

    What is the drop id captured in the log it should be 60001. Check the document here for further information.

    Did you remove the change service to HTTP in action within DNAT policy? Delete the DNAT configuration and recreate it. Check the IP host definition configured for the server has the correct IP address and it is not bind to a particular interface except ANY. 

    Also, take a TCPdump and verify if the packet reaches UTM and then forwarded to the server with the NAT. 

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • If you are referring to viewing the whole log for today, there is nothing with that IP-address.

    I found the default drop in the live log.

     

    Nothing about any drop id, just a timestamp, default drop, TCP protocol, src ip, dst ip, SYN packet/tos/srcmac/dstmac.

     

    I did remove the change service to HTTP in the DNAT policy and I have tried recreating it without any result.

    The IP host definition configuration is checked, it is set to any interface.

     

    I know the packet reaches the firewall, otherwise it would not be seen in the livelogs, right?

     

    EDIT: I found the solution!

    It turns out that I had misconfigured the service HTTP, with source as 80 and destination as 80. It should be any source and destination 80 only.

     

    Thanks for the help!

  • "In the additional address configuration, configure the ISP provided subnet mask on the additional address in place of 32."

    You would think that would be necessary, but it is not.  Many years ago, I had an exchange with Gert Hansen, and he explained that WebAdmin would allow you to use /32 even in the Interface definition, yet still would create the correct routes.  I experimented with that at the time and confirmed it.  Still, I never use that in configurations because it might confuse others.

    For Additional Addresses, there has long been an "undocumented feature" that occasionally results in routing conflicts if you use anything other than /32.  If this issue has been resolved, it was not reported.  Personally, I'm not willing to expose my clients to the possibility that they might have a routing conflict.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?