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

NAT won't forward to DMZ IP

davery23
Hi I have UTM 9.206-35 and I'm rebuilding a DNAT which I had previously forwarded to a windows IIS web server on my internal subnet but now I've built a linux apache server with NICs on my inside and DMZ subnets and I want the outside world to hit the DMZ IP.

It was working when it was set for the inside network destination but after re-creating it doesn't seem to want to work on either side now.

I can see with Inital Packets logged check the traffic hit the external address and allowed by the NAT rule but the destination server doesn't see any activity.

Gateway
Inside: 192.168.4.1
DMZ: 10.1.100.1

Apache host:
Inside: 192.168.4.4
DMZ: 10.1.100.3

DNAT RULE#8: 
FROM:ANY(1:65535/tcp) TO:External (Address)(65080/tcp) DestinationNAT:10.1.100.3(80/tcp)


I see the DNAT in my iptables:
USR_OUTPUT:


USR_PRE:


and I see the initial packets in the live log 

but no matter whether I use automatic or manual firewall rules I see nothing else.

from the looks of the USR_OUTPUT there's 0 packets so it seems like something is breaking down at the rule.


This thread was automatically locked due to age.
Parents
  • 0
    See #5 in Rulz - if your DNAT is changing the service, the new service is what's needed in the Firewall rule.  If it's not being changed, that field should be left empty.  This isn't causing your problem.

    All of your new posts confirm that the problem is outside the UTM.  #3 in Rulz doesn't seem to be the problem, but I bet a packet sniffer on the owncloud_DMZ server NIC would show you the answer.

    Cheers - Bob
Reply
  • 0
    See #5 in Rulz - if your DNAT is changing the service, the new service is what's needed in the Firewall rule.  If it's not being changed, that field should be left empty.  This isn't causing your problem.

    All of your new posts confirm that the problem is outside the UTM.  #3 in Rulz doesn't seem to be the problem, but I bet a packet sniffer on the owncloud_DMZ server NIC would show you the answer.

    Cheers - Bob
Children
No Data