Bad packets, routing problems, NAT fails (?)

bellera

Hello!

Please see attached schema pfSense-2009-12-05.png

I have two pfSense working. The second pfSense (Load Balancer) is at the WAN of the first (Main pfSense).

I have mail and web services published to the Internet at the LAN of the Main pfSense. Each one works on a diferents Internet links, at OPT1 and OPT2 of the Main pfSense.

Everything works fine but the second pfSense is receiving and blocking returning packets for the mail and web services.

I don't know if they are bad packets (no many bad packets at RRD graphics) or is a routing problem or NAT is failing. Routing and ARP tables are ok at the two pfSense boxes.

Any idea? How to know if a packet is a good packet or a bad packet originated by a loss of connection?

Any of our Internet users said to have problems connecting with our Internet services.

Running at the two pfSense boxes:

Version  	 1.2.3-RC3
built on Thu Oct 22 05:53:52 UTC 2009
Platform 	nanobsd

Regards,

Josep Pujadas
pfSense-2009-12-05.png_thumb

bellera

Nobody?

Here a piece of clog -f /var/log/filter.log …

Dec  6 20:06:17 LoadBalancer pf: 15\. 000545 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 48857, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 61.135.162.51.11935: ., cksum 0x5f56 (correct), ack 2035922363 win 0
Dec  6 20:06:22 LoadBalancer pf: 5\. 000120 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 11700, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 61.135.162.51.11935: ., cksum 0x5f56 (correct), ack 1 win 0
Dec  6 20:06:27 LoadBalancer pf: 5\. 000127 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 51259, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 61.135.162.51.11935: ., cksum 0x5f56 (correct), ack 1 win 0
Dec  6 20:06:32 LoadBalancer pf: 5\. 000100 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 12617, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 61.135.162.51.11935: ., cksum 0x5f56 (correct), ack 1 win 0
Dec  6 20:07:02 LoadBalancer pf: 30\. 000981 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 41713, offset 0, flags [none], proto TCP (6), length 40) 192.168.XXX.102.80 > 90.163.254.22.1117: ., cksum 0x106d (correct), ack 1 win 0
Dec  6 20:07:22 LoadBalancer pf: 20\. 000775 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 64170, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 85.58.227.156.1665: ., cksum 0x8bd3 (correct), ack 1466485859 win 0
Dec  6 20:07:22 LoadBalancer pf: 000042 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 53637, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 66.249.71.82.37246: ., cksum 0x8a4a (correct), ack 1599354178 win 0
Dec  6 20:07:32 LoadBalancer pf: 10\. 000305 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 35013, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 208.115.111.246.33302: ., cksum 0x2dc2 (correct), ack 2573597534 win 0
Dec  6 20:07:57 LoadBalancer pf: 25\. 000556 rule 76/0(match): block in on re0: (tos 0x0, ttl 64, id 10048, offset 0, flags [none], proto TCP (6), length 40) 192.168.BBB.2.80 > 67.195.111.152.34658: ., cksum 0x8405 (correct), ack 2838630435 win 0

Rule 76 is, of course, the default rule.

Regards,

Josep Pujadas

Perry

Could it be?
http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F

bellera

Perry,

It could be related but it is quite different …

If you look at the schema you will see that the webserver is using OPT2 at the Main pfSense and the mailserver OPT1 at the Main pfSense.

The "bad packets" go away at the WAN of the Main pfSense and they are logically blocked at the LAN of the second pfSense, named pfSense Load Balancer.

This is because "bad packets" are from OPT2 and OPT1 and sometimes from LAN of the Main pfSense. It seems like the Main pfSense is loosing this packets for any reason and they go away for its default gateway (the WAN). All subnets are different, NAT, routes and ARP tables are correct.

Regards,

Josep Pujadas