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

Hi Eric,

Post the screenshot of the configuration for the additional interface and DNAT policy.

Thanks

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.

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

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

"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