Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 3069 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.
  • 0
    I've deleted and recreated it, restarted the firewall.

    I'm wondering is there any way to tail some logs on the root console to see the DNAT traffic live?

    My apache daemon is up, and the firewall has a rule to allow traffic to the DMZ ip and like I say above it was working when I first switched the IP's between the boxes
    ufw blocking to the inside address:

  • 0
    Some additional information, all my servers are virtual on an ESXi server including my Astaro (okay... I'll call it Sophos :'( hehehe) firewall. I've attached a diagram of this guest machine (it's called cloud, for it runs ownCloud). 

    The diagram is kind of upside-down but I haven't gotten around to relaying out the objects in visio, sorry, just turn your head upside-down as I describe it [[;)]] Some of this is useless but you might have wondered from the stuff I blurred out in the screenshots above what I was hiding so eh, I don't expect anyone to hack my network with all my non-routable IP info [[;)]]

    The 172.16.255.x network is my iSCSI/NFS/SAMBA network to connect my storage server, it is not routed by the firewall and all the guests use it in the same broadcast vlan as the inside network 192.168.4.x. My DMZ broadcast subnet is purely virtual and exists only on the ESXi host vSwitch. Internet Traffic comes in on my modem to my top of rack Dell Powerconnect 5324 and is trunked to the bottom switch over (4) 1Gb fiber conenctions in a LAG on VLAN 96. My virtual UTM system has interfaces for VLANs 96, 192, and 10 (the DMZ on the vSwitch) the dotted purple line connecting the firewalls is just to denote that it's virtual system and the one at the bottom is just a logical depiction.

    I'm hoping Professorem Bob or someone else can help me figure this one out because I'm stuck here. I checked the Rulz and they helped me determine that I didn't have a gateway IP on the NIC in the DMZ on my apache cloud host, so I added along with metrics because I still want the machine to use the inside network for any package updates and it has a crashplan client bound on the inside interface that I use for backups.

    If anyone needs any additional detail please let me know and I'd be happy to put up whatever will help solve this problem.

    BTW in case you didn't notice it in the screen shots for USR_PRE and USR_OUTPUT I have a DNAT for port 80 going to a different guest 10.1.100.4 (a Windows IIS box) and that DNAT is working just fine to that guest.

    Also I turned off the automatic packet filter rule on the DNAT and it's falling back to my packet filter rules on the firewall but the traffic still doesn't seem to be crossing the DNAT.
  • 0
    Hi, Dave, and welcome to the User BB!

    This sounds like a routing problem.  I bet it's #3 in Rulz, but look at #3 through #5.  Any luck with that?

    Cheers -  Bob
  • 0
    yep I think I've checked everything, for 3-5. Like I mentioned in the last bit that 3.1 pointed out that I didn't have a gateway IP set on the DMZ nic of the destination host but after adding and rebooting still no go.

    (route table below on the destination)
    ~$ route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.4.1     0.0.0.0         UG    0      0        0 eth0
    0.0.0.0         10.1.100.1      0.0.0.0         UG    1      0        0 eth1
    10.1.100.0      0.0.0.0         255.255.255.0   U     1      0        0 eth1
    172.16.255.0    0.0.0.0         255.255.255.0   U     0      0        0 eth3
    172.16.255.0    0.0.0.0         255.255.255.0   U     0      0        0 eth4
    172.16.255.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
    172.16.255.0    0.0.0.0         255.255.255.0   U     0      0        0 eth5
    192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

    (arp table on the destination host)
    ~$ arp -n
    Address                  HWtype  HWaddress           Flags Mask            Iface
    192.168.4.10                     (incomplete)                              eth0
    10.1.100.1               ether   00:0c:29:c7:bf:84   C                     eth1
    192.168.4.2              ether   00:0c:29:98:16:97   C                     eth0
    172.16.255.1             ether   00:04:23:9a:bd:92   C                     eth3
    192.168.4.6              ether   00:04:4b:03:c6:84   C                     eth0
    192.168.4.1              ether   00:0c:29:c7:bf:70   C                     eth0
    10.1.100.4               ether   00:0c:29:fa:65:51   C                     eth1
    192.168.4.5              ether   00:0c:29:53:be:64   C                     eth0
    192.168.4.3              ether   00:0c:29:4e:76:fa   C                     eth0


    The UTM didn't have the destination host in the arp table but even after pinging it successfully and verifying it was in the arp cache the DNAT rule still didn't work.

    I'm going to delete everything relative to this DNAT rule (the rule, host definition, service definition) and reboot the firewall and try again.

    Thanks for your time looking at this Bob [:)]
  • 0
    deleted everything, rebooted, rebuilt host and service definitions with new names (Interface: > of course [;)] )

    I see the chains in iptables but still no traffic on the output.

    Is there some log on the server I can watch to find errors besides packetfilters.log that you think might help?
  • 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