[ previous ] [ next ] [ threads ]
 
 From:  Alan Schmitz <alan at ankeny dot net>
 To:  bmah at acm dot org
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Problem with Bridging and NAT
 Date:  Fri, 19 Dec 2003 22:37:18 -0600
On Dec 19, 2003, at 2:55 PM, Bruce A. Mah wrote:

> If memory serves me right, Alan Schmitz wrote:
>> On Dec 18, 2003, at 12:38 PM, Bruce A. Mah wrote:
>>
>>> If memory serves me right, Alan Schmitz wrote:
>>>> On Thu, 18 Dec 2003, Bruce A. Mah wrote:
>>>>
>>>>> I think that further diagnosis might require seeing the IPFilter
>>>>> rulesets installed on your m0n0wall box.  Is it possible for you to
>>>>> get
>>>>> this output and post some sanitized version of them?
>>>>
>>>> I'll post a cleaned-up version of my rules, when I'm back on the LAN
>>>> side
>>>> of the firewall tonight.  I'm also going to run a tcpdump from the
>>>> server
>>>> in the DMZ.
>>>
>>> OK, that'll be helpful information.
>>
>> I ran tcpdump on the server in the DMZ, and it looks like the bridge 
>> is
>> working correctly.  pings get to the server, and it sends responses
>> back to the firewall.
>
> You did pings from...where?

Sorry... the pings originated from a workstation in the LAN.

>> I pasted the rules from the output of the status.php page below.  sis0
>> is the LAN, sis1 is the WAN, and sis2 is the DMZ.  .25 is the
>> firewall's IP address on the WAN, and .29 is the address of the server
>> in the DMZ.
>
> I'm not an expert with IPFilter (and in fact one of the reasons I use
> m0n0wall is because I'm too lazy to try to maintain my own rulesets!).
> But I didn't see anything really obviously wrong in the rules that
> m0n0wall generated for you.

I'm trying to switch to m0n0wall for the very same reason.  It looks 
like I'll have to dig into ipfilter at least enough to follow the 
basics of rule processing.  Not much is obvious to me at this point.

>> I did some additional testing between the LAN and the DMZ.  When I 
>> ping
>> the server in the DMZ from a workstation on the LAN, I don't get any
>> entries in the firewall log.
>
> Did the workstation receive the ICMP ECHO_REPLY packets?  (== did ping
> do the right thing?)

The replies from the workstation on the LAN were not received, so no it 
didn't do the right thing.

>> If I try to connect to port 80 on the DMZ
>> server from the LAN workstation, I get the following errors in the
>> firewall log:
>>
>> 19:40:05.789513 sis2 @0:12 B aaa.bbb.ccc.29,80 -> aaa.bbb.ccc.25,8628
>> PR tcp len 20 48 -AS IN
>> 19:39:17.337786 sis2 @0:12 B aaa.bbb.ccc.29,80 -> aaa.bbb.ccc.25,8628
>> PR tcp len 20 48 -AS IN
>> 19:38:52.967931 sis2 @0:12 B aaa.bbb.ccc.29,80 -> aaa.bbb.ccc.25,8628
>> PR tcp len 20 48 -AS IN
>> 19:38:40.038532 2x sis2 @0:12 B aaa.bbb.ccc.29,80 ->
>> aaa.bbb.ccc.25,8628 PR tcp len 20 48 -AS IN
>> 19:38:34.029709 2x sis2 @0:12 B aaa.bbb.ccc.29,80 ->
>> aaa.bbb.ccc.25,8628 PR tcp len 20 48 -AS IN
>> 19:38:31.075338 sis2 @0:12 B aaa.bbb.ccc.29,80 -> aaa.bbb.ccc.25,8628
>> PR tcp len 20 48 -AS IN
>
> I can't find a good reason for m0n0wall to reject these packets.  I
> thought that what should happen is that the original SYN packets from
> the workstation should set up connection state inside IPFilter's state
> tables, and then they should automatically be passed thereafter.
>
> The output of "ipfilter -sl" might help you a little bit to figure out
> if this is happening but I'm starting to get out of my league here.
> In other words, if you repeat your "connect to port 80 on the DMZ
> server" experiment, does "ipfilter -sl" on the m0n0wall box show any
> connection state for the attempt or not?  It should, although it's not
> clear to me if the originating IP address would be your workstation's
> IP address or the address of the m0n0wall box's WAN-facing interface.

I'm hoping you meant "ipfstat -sl".  If you did, and this means what I 
think it does, it looks like the connection state is being setup:

    192.168.1.30 -> aaa.bbb.ccc.29 ttl 356 pass 0x500a pr 6 state 2/0
	   pkts 6 bytes 288	3194 -> 80 b7d78220:0 64240<<0:1<<0
	   pass in quick keep state	IPv4
	   pkt_flags & 2(b2) = b,		pkt_options & ffffffff = 0
	   pkt_security & ffff = 0, pkt_auth & ffff = 0
	   interfaces: in sis0,- out sis1,-

The only part that looks off is the "out sis1" part.  sis1 is the WAN 
interface, but the .29 server is connected to the sis2 (DMZ) interface. 
  If the NAT is watching for the traffic to return specifically on the 
sis1 interface, it's not going to match.

That's just another theory, but I've been in way over my head for quite 
a while now.

-Alan