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

Rule for dropping packets destined for a remote subnet

AlexE
Hi all,
Forgive me if I've missed something obvious here, it's been a long weekend!

My ASGv7 has, aswell as it's internet interface:
One NIC connected to a 192.168.1.0/24 subnet called 'DMZ1'
One NIC connected to a 192.168.2.0/24 subnet called 'DMZ2'

The 192.168.1.0 subnet has a router on it which is in turn connected to a 192.168.3.0/24 subnet called 'Inner_LAN'
The 192.168.2.0 subnet has a webserver on it (192.168.2.2)

I have a network definition for 'HostPC' (192.168.3.2), and for 'Inner_LAN' (192.168.3.0/24)

I wish to setup packet filter rules to allow internet access from the webserver, but block traffic originating at the webserver, which is destined for hosts on the 'remote' 192.168.3.0 subnet (behind the router).

I've tried the following rules in the order shown:

1 - Source: DMZ2 (Network),   Service: Any,   Destination: Inner_LAN,   Action: drop
2 - Source: DMZ2 (Network),   Service: Any,   Destination: HostPC,       Action: drop
3 - Source: DMZ2 (Network),   Service: Any,   Destination: Any,           Action: allow

What I expect should happen is that when attempting to send traffic from the webserver (192.168.2.2) to hostPC (192.168.3.2), the first rule should match, as the hostPC address is on the 'Inner_LAN' network.
Failing that, the second rule should certainly match as the traffic is destined for the exact IP address of the defined 'HostPC'.
However, what is actually happening is that the third rule is being applied and the traffic is being allowed through.
Why is this?


This thread was automatically locked due to age.
Parents
  • 0
    Do you have the http proxy enabled?

    What type of traffic are you generating to test this? In the packet filter log what do you see with logging enabled for the rules?
  • 0 in reply to dilandau
    Hi Dilandau,
    Thanks for taking the time to read my post, and reply
    I don't have the http proxy enabled, but the problem I'm having relates to all traffic, not just http/https.
    As well as sending http and https traffic using Internet Explorer, I've tried VNC connections using port 5900, and also telnet connections on port 25. All produce the same results I described. I know that the third rule in my list is being applied, from the entries in the packet filter log.
  • 0 in reply to AlexE
    The traffic should be dropped, it is strange that it would not match the first 2 rules.

    One alternative to just allow the DMZ2 access to the internet is to create your own "Any" definition and specify to bind it to the external interface, so it will just allow traffic to leave that interface. Of course it won't explain why the traffic isn't being dropped by your packet rules, but it will allow you to setup the access that you want.
  • 0 in reply to dilandau
    Thanks for the suggestion! [:)]
    I'm not quite sure just how I'd go about that, but you got me thinking and I have found what seems like a reasonable (albeit a bit 'clunky') workaround;
    I set up a NAT rule which translates the destination IP of any traffic, originating from my DMZ2 subnet (e.g. the webserver), which is destined for my remote 'Inner_LAN' subnet, into a non-existant host IP in the DMZ2 subnet. Effectively, any traffic which the webserver tries to send to my remote 'Inner_LAN', is simply turned around and sent back. Of course, the 'new' destination IP doesn't actually exist.
    I tested a telnet connection from my webserver to a host on my Inner_LAN and telnet simply reports 'no route to host'. By disabling the 'Automatic packet filter rule' in my NAT rule definition, I can see from the packet filter log that 'rule 3' (from previous) is matching the traffic, and indicating that the destination has been changed to my 'dummy host'.

    This seems to work, but I'm still curious about what was wrong with my original packet filter rule!

    Also, I'm still interested in your suggestion as it may well be a more elegant solution than mine, and would appreciate it if you'd expand a little on just how I'd apply the config so I can try it out.

    Thank you
  • 0 in reply to AlexE
    I've figured out what was wrong with my original config;
    Whilst having a look at another thread in this category called 'DNAT madness' something caught my eye, prompting me to check the definitions for my 'Inner_LAN' network and the HostPC on it. Turns out they were wrong!
    The 'Inner_LAN' subnet is seperated from my ASG by a router, as I'd mentioned earlier. However, I'd stated in each definition that the host / network was bound to the 'DMZ1' interface of my ASG, which of course they aren't, because they're on a different subnet on the other side of a router!
    I've set the interface to > in each definition, my packet filter rules now work as I originally expected, and once again I can relax knowing that I'm not loosing it (phew!).

    Happy days [:D]

    Thanks
Reply
  • 0 in reply to AlexE
    I've figured out what was wrong with my original config;
    Whilst having a look at another thread in this category called 'DNAT madness' something caught my eye, prompting me to check the definitions for my 'Inner_LAN' network and the HostPC on it. Turns out they were wrong!
    The 'Inner_LAN' subnet is seperated from my ASG by a router, as I'd mentioned earlier. However, I'd stated in each definition that the host / network was bound to the 'DMZ1' interface of my ASG, which of course they aren't, because they're on a different subnet on the other side of a router!
    I've set the interface to > in each definition, my packet filter rules now work as I originally expected, and once again I can relax knowing that I'm not loosing it (phew!).

    Happy days [:D]

    Thanks
Children
No Data