News: This forum is now permanently frozen.
Pages: [1]
Topic: Problem with blocked packets on the Lan network  (Read 3962 times)
« on: April 13, 2010, 18:15:26 »
Trent *
Posts: 10

In advance thanks for any help you can give me with this issue.  I'm having an odd problem with blocked packets on the LAN network.  I have a bit of an odd setup in that I have a router on my LAN network that further segments my network.  I do need hosts that are behind the router to be able to see the hosts that are in the LAN network.  The basic setup looks like this ...


    192.68.40.X   ----- Router with ip addresses 192.168.40.1 and 192.168.65.2 ----  DMZ Network ----- M0n0Wall (65.1) ---- Internet

Currently I only have one host in the DMZ 192.168.65.5

when I try to ping it from a host in the 40 network the ping requests arrive at the host but the replies back are blocked by M0n0wall

I have included some screen shots with relevant information.


* fwblocks.jpg (62.49 KB, 565x331 - viewed 235 times.)

* lan-rules.jpg (40.4 KB, 584x456 - viewed 230 times.)

* outboundnat.jpg (43.01 KB, 613x351 - viewed 220 times.)

* Static-Routes.jpg (20.44 KB, 604x159 - viewed 234 times.)
« Reply #1 on: April 13, 2010, 18:34:49 »
Trent *
Posts: 10

Some additional information using http://doc.m0n0.ch/handbook/troubleshooting-firewall-rules.html I found that the following:



Code:
Apr 13 16:26:44 m0n0wall ipmon[123]: 16:26:44.023113 em0 @100:8 b 192.168.65.5 -> 192.168.40.52 PR icmp len 20 84 icmp echoreply/0 IN


# Group 100
@1 pass in quick from 192.168.65.0/24 to 192.168.65.1/32 keep state group 100
@2 pass in log first quick from 192.168.65.0/24 to any keep state group 100
@3 pass in log first quick from 192.168.40.0/24 to any keep state group 100
@4 pass in log first quick from 192.168.2.0/24 to any keep state group 100
@5 pass in log first quick from 192.168.65.5/32 to any keep state group 100
@6 pass in log first quick from any to 192.168.65.5/32 keep state group 100
@7 pass in log first quick proto icmp from any to any keep state group 100
@8 block in log first quick from any to any group 100

So it appears to be a state problem ... I am guessing because the initial connection did not come through the m0n0wall but the reply does.  Any advice on correcting this problem?

« Reply #2 on: April 13, 2010, 20:16:33 »
brushedmoss ****
Posts: 446

you need to add a static route on m0n0wall pointing to your router for that subnet

i.e. 192.68.40.0/24 via 192.168.65.2
« Reply #3 on: April 13, 2010, 22:07:16 »
Trent *
Posts: 10

If you look at the attached Static-Routes.jpg   you will see that that rout exists already
« Reply #4 on: April 14, 2010, 02:31:46 »
brushedmoss ****
Posts: 446

Oops missed that. I think you are correct. You might be able to do this via secondaries for routing to make the first packet route through monowall.
otherwise add routes to internal supernets to. 2 on your dmz hosts
« Reply #5 on: April 14, 2010, 15:01:35 »
mtnbkr *
Posts: 2

Bottom of WAN page  UNcheck "Block private networks"
« Reply #6 on: April 14, 2010, 16:41:54 »
Trent *
Posts: 10

The Block Private networks is unchecked (Sorry forgot to take a pic of that one)
« Reply #7 on: April 14, 2010, 16:43:53 »
Trent *
Posts: 10

Oops missed that. I think you are correct. You might be able to do this via secondaries for routing to make the first packet route through monowall.
otherwise add routes to internal supernets to. 2 on your dmz hosts

Is there a reason M0n0wall blocks these packets ... is there a workaround in M0n0wall .. I know I can set routes on my DMZ hosts but I would rather not manage those routes on an individual host basis.
« Reply #8 on: April 14, 2010, 22:46:31 »
brushedmoss ****
Posts: 446

As m0n0 is seeing an icmp reply that it can't match to the echo request and it's a stateful firewall , it's dropping the reply.  I assume a ping from 192.168.65.5 to the host on the .40 network works ?  Also TCP such as http will only work from 65 to 40 nets and not 40 to 65.

With a new baby in my house I'm kinda tired so my brain is not working at capacity, and the fact I haven't seen this reported before for such a simple setup makes me think I may be wrong.

The secondaries feature is fairly basic and I can't test the theory, but you may be able to assign a secondary of say 192.168.70.1 to m0n0 and 192.168.70.2 to your internal router and add a static to the internal router pointing 192.168.65.0/25 via 192.168.70.1 which may work around the problem (forcing the syn or echo request through m0n0).  But I don't remember that code path well at the moment...

« Reply #9 on: April 14, 2010, 23:55:13 »
Trent *
Posts: 10

As m0n0 is seeing an icmp reply that it can't match to the echo request and it's a stateful firewall , it's dropping the reply.  I assume a ping from 192.168.65.5 to the host on the .40 network works ?  Also TCP such as http will only work from 65 to 40 nets and not 40 to 65.

With a new baby in my house I'm kinda tired so my brain is not working at capacity, and the fact I haven't seen this reported before for such a simple setup makes me think I may be wrong.

The secondaries feature is fairly basic and I can't test the theory, but you may be able to assign a secondary of say 192.168.70.1 to m0n0 and 192.168.70.2 to your internal router and add a static to the internal router pointing 192.168.65.0/25 via 192.168.70.1 which may work around the problem (forcing the syn or echo request through m0n0).  But I don't remember that code path well at the moment...




Thanks for all of the info (And congrats on the Baby).... I would be interested to know if there were another way around it.  Adding the secondary ip makes sense but it just seems to add to the network complexity
« Reply #10 on: April 15, 2010, 10:24:07 »
brushedmoss ****
Posts: 446

Thanks !

To do what you want, stateful inspection would have to be turned and that is probably not a good idea, even if it's done at a granular level.   When I look at how I install firewalls for this type of use case, I typically have an outside (WAN) interface, and inside (LAN) interface and a DMZ or multiple DMZ interfaces (OPT).  The inside interface has no hosts and is connected to the inside router like you have, and my DMZ hosts are on a dedicated interface so I don't encounter this issue and it's a model I find works well.

Would you consider adding another NIC for your DMZ hosts ?
« Reply #11 on: April 15, 2010, 16:36:34 »
Trent *
Posts: 10

Thanks !

To do what you want, stateful inspection would have to be turned and that is probably not a good idea, even if it's done at a granular level.   When I look at how I install firewalls for this type of use case, I typically have an outside (WAN) interface, and inside (LAN) interface and a DMZ or multiple DMZ interfaces (OPT).  The inside interface has no hosts and is connected to the inside router like you have, and my DMZ hosts are on a dedicated interface so I don't encounter this issue and it's a model I find works well.

Would you consider adding another NIC for your DMZ hosts ?


Thats probably the best way to go about this ... my problem is my M0n0wall is now a plane flight away from me ... although next time I am out that way I will add another nic to the box.  In the mean time is there a way to disable stateful inspection for specified traffic?  The alternative is to push local routes on the boxes which bypasses the M0n0wall any how.

« Reply #12 on: April 15, 2010, 17:01:46 »
brushedmoss ****
Posts: 446

I'll have a peek and see what's involved.

Another option is to use VLAN's on m0n0wall so the one nic can do the role of two, but depends on you cisco switch and router etc.
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines