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

Traffic from 172.16.0.1 (in DMZ) going to ip on external interface goes back to dmz

This is a slight mind bender but here goes.

In my dmz I have the web server at 172.16.0.1, I want it to be able to access itself as 12.34.56.78 which is an additional interface as part of the external wan.

Now, I have already got it working for the lan and internet. So, anybody who connects to 12.34.56.78 connects to the webserver. (dnat)

I've been experimenting with source nat and so far have failed to get it working.

So, in otherwords.. when 172.16.0.1 tries accessing 12.34.56.78 in a web browser the firewall redirects the traffic back to 172.16.0.1 whilst keeping 172.16.0.1 oblivious.

This isn't ultra important as a simple workaround has been me putting in the domains that go to the ip as 127.0.0.1 hosts in the hosts file on the web server itself.

It's more of a scratching head how the heck do you do that kind of thing.


This thread was automatically locked due to age.
  • Mark, I think I must not understand what you're trying to accomplish.

    Position: {remember the rules are processed in order}
    Traffic Source:  172.16.0.1 
    Traffic Service:  Any
    Traffic Destination:  12.34.56.78
    NAT mode: SNAT
    Source: {it makes no sense to change the source to 172.16.0.1}

    If you have another device inside the DMZ at, for example, 172.16.0.2 that can get to 172.16.0.1 via 12.34.56.78, then 172.16.0.1 should be able to do so also.  No SNAT required.

    Cheers - Bob
  • The odd thing is that I do have dnat setup for the address and it works perfectly for incoming on the wan interface and the internal lan interfaces but not on the dmz.

    So, for example when I access 12.34.56.78 on the local lan in a web browser the firewall sends the traffic to 172.16.0.1. But when doing the same from 172.16.0.1 itself it doesn't work.
  • If 172.10.0.2 could access 172.10.0.1 via 12.34.56.78, you would know that you have allowed the traffic.

    If you want to be able to use the HTTP Proxy as you are for the internal lan, you need to add your DMZ network to 'Allowed Networks' on the 'Global' tab of HTTP Proxy.

    Otherwise, you need a packet filter rule to allow the traffic from 172.10.0.1 to 12.34.56.78.

    Cheers - Bob
    PS I still don't understand why you would want to access 172.10.0.1 by such a circuitous route
  • If 172.10.0.2 could access 172.10.0.1 via 12.34.56.78, you would know that you have allowed the traffic.

    If you want to be able to use the HTTP Proxy as you are for the internal lan, you need to add your DMZ network to 'Allowed Networks' on the 'Global' tab of HTTP Proxy.

    Otherwise, you need a packet filter rule to allow the traffic from 172.10.0.1 to 12.34.56.78.

    Cheers - Bob
    PS I still don't understand why you would want to access 172.10.0.1 by such a circuitous route


    Essentially a few reasons.

    When accessing the web servers addresses which resolve to 12.34.56.78 to work correctly.
    For example, I go into a web browser on the web server and go to exampledomain.com which resolves to 12.34.56.78. The web server won't be able to access that unless I play with the hosts, point the web server to a dns server other than our isp dns servers (and change the dns of those addresses) or tweak the firewall so it correctly redirects the traffic back to the web server.

    Also, we have some bespoke software on the web server provided by a third party which for support reasons we cannot tweak which looks to these domains. (like I said, for the moment i've just changed the hosts file on the server to point to localhost for the addresses)
  • Any reason to not run a DNS process on your DMZ webserver and add lookup zones specifically for your purposes?

    CHeers - Bob