Hi, i've setup a 'private subnet' in my home network. I have a 'server' which has two nic's eth0 is connected to the ADSL modem/router and eth1 is connected to a switch connecting all pc's on the subnet. The server runs vmware server and runs 3 VM's: - ubuntu bridged to eth0 - ubuntu bridged to eth1 - m0n0wall which acts as the firewall/gateway/dhcp server for the subnet. the "WAN" interface is bridged to eth0 and the "LAN" interface to eth1 At this stage only the dhcp server is enabled and dns forwarding so that machines on the subnet can access the internet. The setup works DNS names are resolved and 'most' websites work fine. ping to various hosts returns the same values via the m0n0wall as directly through the modem/router gateway. However, some sites take ages to load, or don't load at all. But not always. www.bbc.co.uk is one example. I'm using wireshark to get to the bottom of the problem but so far i've only found that the times the request fails the server (bbc) sends an window-update as a response to the packet with the GET request. After that the client retransmits two more times and the server finally responds with 'bad tcp'. What i'm trying to find out is whether i've got a config problem in the m0n0wall or whether its more fundamental e.g packets getting mangled etc. any pointers would be appreciated. cheers, Michael asked 10 Aug '11, 14:13  mmalaprop |
2 Answers:
If some sites work directly, but not over the m0n0wall firewall, then I would make traces on both sides of the m0n0wall and compare them. Look at the TCP options for things like:
What exactly do you mean with "the server responds with 'bad tcp'"? Is that an HTTP message? Or is it wireshark reporting a packet as bad tcp? answered 11 Aug '11, 00:08  SYN-bit ♦♦ |
I used tcpdump to monitor both physical interfaces. and imported the results into wireshark. There i used "follow tcp stream". On the eth0 side there are more packets being sent, i was kind of expecting them to be one-to-one. I looked at the packets (not all ) and they don't seem to be corrupted or have their options reset. eth1: eth0: thanks, michael answered 11 Aug '11, 12:13 mmalaprop 3 Ah... these traces explain things. Your ADSL modem/router (192.168.1.1) it telling your client (192.168.1.95 after nat, 192.168.2.2 before nat) that it needs to fragment the IP datagram to forward it (see frames 28, 50, 89). However the m0n0wall does not seem to forward these ICMP packets. So your client does not learn that it needs to send smaller packets. You can solve this by looking at the ICMP packet in frame 28 and extract the MTU of the next hop. You can then change the MTU size on both sides of the m0n0wall FW accordingly. (11 Aug '11, 12:29) SYN-bit ♦♦ That did it! thanks. Just so this is clear in my head... the client (192.168.1.95) sent a packet (frame 24 say, 1514 bytes). this had the DF flag set and the router dropped that packet and sent a 'this is to big for me to forward - please fragment'. what i don't quite understand:
(11 Aug '11, 15:51) mmalaprop 1 Actually, to be precies, the meaning of the ICMP paket is: "You want me to forward a IP packet without fragmenting, however, it is too big for the link towards the next hop. I can only send IP datagrams of size XXX, so I dropped the packet" Then it's up to the sending host to determine what to do. In TCP, the sending host will just start to use smaller segments so that they will fit. (11 Aug '11, 23:23) SYN-bit ♦♦ 1 I would have expected the m0n0wall to forward the ICMP messages, so you might want to report this as a bug (or feature request, depending how you look at it). A 1500 byte MTU means that a 1500 byte datagram can be transported over the link, which on ethernet means there will be a 6 byte destination, a 6 byte source and a 2 byte ethertype prepended and a 4 byte FCS appended to the datagram. In total 1518 (although you usually see 1514 in Wireshark because the FCS is already stripped before Wireshark gets to see the packet). (11 Aug '11, 23:25) SYN-bit ♦♦ I think m0n0wall drops all incoming communications, including ICMP (which is sort of belonging to the TCP session but has no entry in its firewall state table since it's a new communication flow). I would advise to configure m0n0wall to drop all ICMP packets except "fragmentation needed" (if that's possible). (12 Aug '11, 05:59) Jasper ♦♦ @Jasper, just letting the "ICMP fragmentation needed" packets through is not enough, these packets need to be properly natted (at the IP layer as well as at the IP layer inside the ICMP payload). m0n0wall needs to bind these ICMP packets to the outgoing TCP flow to be able to do so. I have seen this being a problem with loadbalancers in the past as well. (12 Aug '11, 06:28) SYN-bit ♦♦ the m0n0wall comes with a setting 'block private networks' on its WAN interface. i did disable that earlier and assumed it would include ICMP packet. it didn't. i allowed ICMP traffic to pass through but still the 'fragmentation needed' packets didn't pass. i'll see if the m0n0wall folks know anything more. (13 Aug '11, 14:49) mmalaprop Just one more thing on this issue:-) the IP 192.168.1.95 is that of the m0n0wall, which must NAT that to 192.168.2.2 (the client is in the subnet). But that makes sense right? the m0n0wall is acting as a gateway from the .1.0 network to the .2.0 network. (14 Aug '11, 11:54) mmalaprop showing 5 of 8 show 3 more comments |
thanks for your response.
"bad tcp" was what wireshark called the packet. the way i saw it was the server sent a window-update and that was marked by wireshark as a bad tcp and coloured red. also, the two subsequent retrnasmitts were marked red (bad tcp). the final packet was an RST - reset. i guess that was the end of the communication.
the successfull transmitts also had some retransmits and window-update just a lot less.