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

packet filter rule fires - but no packet is found

KBB
Hi,

I am trying to give an external IP address access to an internal (RMI) server behind the ASG. So I have a DNAT rule to redirect the incoming packet to the internal server, and I have a Packet filter rule which allows this particular external IP to get through to the internal server.
In the log I can see the DNAT rule applied, followed by the PF rule. But there is no packet going to the internal server! I am checking all the traffic to/from the server with a network monitor.
If I do the same thing from within the LAN (behind the ASG) everything works fine and I can see all the packets to/from the server.

Here is the packet filter rule from the log:

2011:05:25-16:06:32 oecwall ulogd[5255]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="18" initf="ppp0" outitf="eth0" srcmac="0:8:54:57:13:63" srcip="80.187.107.68" dstip="192.168.115.58" proto="6" length="64" tos="0x00" prec="0x00" ttl="111" srcport="55624" dstport="2004" tcpflags="SYN" 

It correctly shows the external IP translated by DNAT to the internal "192.168.115.58".

What can possibly happen to the packet after having passed the packet filter rule?
Grateful for any ideas,

Thanks,
Klaus


This thread was automatically locked due to age.
  • 0
    Hi Klaus,

    Is this target server using the ASG as it's gateway to the Internet as well?
  • 0 in reply to AngeloC
    Hi Klaus,

    Is this target server using the ASG as it's gateway to the Internet as well?


    Yes, it is. The external IP send its request to the gateway:2004 and the DNAT rule translates this to internal:2004.

    More precisely: the ASG goes to the internet through a DSL router (Fritzbox).
  • 0 in reply to KBB
    Ah ok, so to be clear, the server which your trying to reach behind the ASG is also using the ASG as a gateway right? Did you check the fritz to see if the packet is getting only to there and then getting lost?
  • 0 in reply to AngeloC
    I'm sorry, not sure what you mean. The external packet goes through the "Fritz" to the ASG, gets DNAT'ed to point to the internal server on the LAN, the packet filter rule lets it pass - so, for me, it should go from the ASG to the server without passing through the Fritz again?
  • 0
    Try deleting the pf rule and just do Auto pf rule on the DNAT rule.
    I assume the destination box has no firewall that may be blocking?  Can you install Wireshark or similar on the box to see packets coming from the firewall?
  • 0
    Hi, KBB, and welcome to the User BB!

    What Angelo was saying is the your issue sounds like a common one: someone adds an Astaro to their network, and DNATS don't work.  Usually, this is because of the "default gateway" setting in the computer behind the Astaro.  In your case, the device with the IP 192.168.115.58 needs to have the IP of the Astaro's 'Internal (Address)' as its gateway.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    First of all, thanks for your efforts and sorry for having been disconnected for a while.
    The external access to our internal RMI server is working okay now. The DNAT and PF rules were correct, but the RMI server behind the Astaro had the Windows Firewall active which apparently blocked the access. Switching it off everything worked as it should.
    In case someone has difficulties in opening an RMI application to the outside, feel free to contact me as there are other non-trivial (non-firewall) issues involved which kept me investigating for many days.
    BTW, I kept my specific pf rule for a single IP address in order to allow very selective access to our RMI application.

    Klaus Blass
    OEC AG
    Munich - Germany
Unfiltered HTML