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

Dnat

FICS
Hello everyone,

Please forgive me; I'm working on only a few hours of sleep this year so I'm hoping that this is just a silly oversight on my behalf that is easily fixed:

I don't want to post unedited firewall logs here so I'll do my best to make this easy to understand without missing too much information.

I have several NAT rules set up in my UTM.  I can see outside connections being made and accepted to these NAT rules but then something odd happens: the connection is blocked going back out to the requester.



Here's a snippet from the logs: 

2015:01:07-16:34:49 74 ulogd[20893]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62012" initf="eth1" srcmac="((Requestor's MAC))" dstmac="((UTM's MAC))" srcip="((Known IP of Requester))" dstip="((eth1 WAN IP))" proto="6" length="48" tos="0x08" prec="0x20" ttl="112" srcport="30148" dstport="55550" tcpflags="SYN" 

2015:01:07-16:34:49 74 ulogd[20893]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="br0" outitf="eth1" srcmac="((Requestor's MAC))" dstmac="((UTM's MAC))" srcip="((eth1 WAN IP))" dstip="((Known IP of Requester))" proto="6" length="48" tos="0x00" prec="0x00" ttl="126" srcport="55550" dstport="30148" tcpflags="ACK SYN" 

2015:01:07-16:34:49 74 ulogd[20893]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="br0" outitf="eth1" srcmac="((Requestor's MAC))" dstmac="((UTM's MAC))" srcip="((eth1 WAN IP))" dstip="((Known IP of Requester))" proto="6" length="48" tos="0x00" prec="0x00" ttl="126" srcport="55550" dstport="4308" tcpflags="ACK SYN" 

2015:01:07-16:34:49 74 ulogd[20893]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="br0" outitf="eth1" srcmac="((Requestor's MAC))" dstmac="((UTM's MAC))" srcip="((eth1 WAN IP))" dstip="((Known IP of Requester))" proto="6" length="40" tos="0x00" prec="0x00" ttl="126" srcport="55550" dstport="48752" tcpflags="RST" 

2015:01:07-16:34:52 74 ulogd[20893]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="br0" outitf="eth1" srcmac="((Requestor's MAC))" dstmac="((UTM's MAC))" srcip="((eth1 WAN IP))" dstip="((Known IP of Requester))" proto="6" length="48" tos="0x00" prec="0x00" ttl="126" srcport="55550" dstport="30148" tcpflags="ACK SYN" 


So what I'm seeing is that the request comes in on the port that I'm expecting and it is accepted.  After that the firewall drops my packets from my UTM's WAN IP on their way back to the requester's IP.

The DNAT rules are built the same way I've built them a hundred times before.  Intrusion Protection is off.  Advanced Threat Protection is off.  Application Control is not licensed and is disabled as well.

UTM v9.305-4

Help.


This thread was automatically locked due to age.
  • 0
    For what it's worth, here's a shot of the DNAT.  Sorry I blacked everything out but I think that the important parts are still present:
  • 0
    Update (for anyone reading that might be reading this thread in the future and for my own sanity)

    Using this thread I found a link to the protocol numbers here and have verified that the traffic coming in is TCP (protocol 6).

    Using that, I went back to my service definition for 55550 and verified that it is configured for TCP as well.

    The destination service has also been verified as being TCP and connections made internally (IE without DNAT) work flawlessly.
  • 0
    Update:  just got off the phone with Lucky from Sophos Support:

    It appears that when I created the NAT rule the automatic firewall rule that the UTM created was flawed somehow.  After we added our own rule allowing the traffic to flow from the UTM's WAN Network to the known IP of the requester traffic began to flow nicely and the firewall logs didn't show the blocked traffic any longer.

    I'm not totally satisfied with this fix because we will have requests coming in from dynamic addresses in the future that will cause this to break.

    I'm tempted to add a line in the firewall that says something like this (but it seems seriously redundant):
    WAN Network > Any > Any Internet IPv4 Allow

    Does anyone see flaw in that?
  • 0
    Update:  ok the 'fix' that I used in the above case doesn't seem to fully work; when I attempt to connect using a port forwarded (DNAT) RDP session I get "A network error has occurred".

    This tells me that I'm connecting but not fully and I'm not sure where the connection is falling apart since I can't seem to find anything in the logs.


    A few more tidbits of information that may spark someone's imagination:
    1.  I have bridged eth0 and eth5 for the LAN here
    2.  The WAN IP has changed several times during the testing of this equipment.  We have used both static and dynamic IPs prior to the actual deployment.  I fear that this may be causing problems somewhere behind the scenes.
    3.  I have two static routes built so that traffic on the LAN may access two other LANs using eth2 and eth3.

    I don't know if any of those points are going to help solve this situation and honestly other than point #2 I can't see where issues would arise.  I have disabled the routing to see if that was causing issues however there was no change.

    As for point #2, if I knew where to look or what to do I would delve more deeply into that.  Some small part of me wants me to delete the interface and rebuild it but I think that might be more work than it's worth seeing as I have 30-some-odd NAT rules built that use the eth1 WAN connection.
  • 0
    Without confirmation, I would hesitate to accept the theory of a "bad" auto firewall rule.

    First, please check the Intrusion Prevention log to confirm that no Anti-DoS activity is logged.  Also, check #3 through #5 in Rulz.  Any luck with any of that?

    Cheers - Bob
  • 0
    Thanks for the reply Bob,

    Rulz:  Rule #3 is something that I learned (the hard way) years ago ;-)
    Rule #5 is something that I will review and consider.

    Intrusion Prevention is still turned off so consequently there's nothing appearing in that log.

    After another call with Sophos support (we still can't get it to work after being on for well over an hour) and several TCP dumps later, here's something that's sticking with me:

    13:35:08.432884 IP ((Known Requester's IP)).52545 > 74.55545: Flags [P.], seq 1:20, ack 1, win 16695, length 19
    ^C


    See how the IP is trunked after the forward?  It simply says "74" rather than the full WAN IP address of the UTM.  From the TCPdumps that I've seen in the past I think that this is the problem: the full IP address should appear here.

    I have checked the hostname and the ethernet configuration and both contain the full IP address of the UTM.  The internet connection works on the UTM just fine for requests originating on the network to the outside world.

    I have a feeling that something got messed up when I changed the hostname and/or WAN IP address and I mentioned that to Support but they decided to pass me on to the ISP for further clarification.  Of course, the ISP tells me that traffic is flowing through them normally.

    More information:  this is a retrofit where we are removing a functioning Cisco and replacing it with this UTM.  (The Cisco lacks capabilities that we need for this site).  I am very hesitant to blame the ISP for anything since we cloned all of the rules from the Cisco into the UTM.  All of the port redirection was working prior to the change.
  • 0
    Ok, so having looked at some more TCP dumps I see that this isn't the case...  The hostname up to the first period appears there.