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

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.
Parents
  • 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.
Reply
  • 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.
Children
No Data