Bad packets, routing problems, NAT fails (?)



  • 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



  • 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,

    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


Log in to reply