Re: [pfSense] Disable antispoofing on an interface
That block is on a TCP packet, not UDP. Also, is there something on the othersid Yudhvir On Jul 17, 2014, at 4:26 PM, Adam Thompson athom...@athompso.net wrote: On 14-07-17 12:32 PM, NetSys Pro wrote: Here's the output: Jul 17 21:27:50 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 0, length 64 Jul 17 21:27:52 fw2 pf: 00:00:01.885014 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 1, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:52 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 2, length 64 Jul 17 21:27:52 fw2 pf: 00:00:00.358395 rule 5/0(match): block in on re2: (tos 0x0, ttl 128, id 1110, offset 0, flags [DF], proto TCP (6), length 40) Jul 17 21:27:52 fw2 pf: 192.168.6.106.54118 23.214.64.109.443: Flags [R.], cksum 0x4fe4 (correct), seq 1951833685, ack 1897326514, win 0, length 0 Jul 17 21:27:53 fw2 pf: 00:00:00.628387 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 2, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:53 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 3, length 64 Jul 17 21:27:54 fw2 pf: 00:00:01.148349 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 3, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:54 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 4, length 64 Jul 17 21:27:55 fw2 pf: 00:00:00.874917 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 4, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:55 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 5, length 64 Jul 17 21:27:56 fw2 pf: 00:00:01.011050 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 5, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:56 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 6, length 64 Jul 17 21:27:57 fw2 pf: 00:00:00.989951 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 6, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:57 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 7, length 64 Jul 17 21:27:58 fw2 pf: 00:00:00.995826 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 7, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:58 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 8, length 64 Jul 17 21:27:59 fw2 pf: 00:00:01.031938 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 8, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:59 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 9, length 64 Jul 17 21:28:00 fw2 pf: 00:00:00.971443 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 9, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:28:00 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 10, length 64 Jul 17 21:28:01 fw2 pf: 00:00:01.040452 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 10, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:28:01 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 11, length 64 What do you think? Since there's only one block in that list, I'm going to speculate that it represents your missing packet. Also, it refers to re2 which is likely your OPT1 interface if you did things conventionally. I don't know what rule 5 is, although anything with that low a # is likely to be a system-generated rule. On my system, it's the Default deny rule IPv6, although that doesn't sound likely in your case. You'll want to run pfctl -vv -s rules | more and tell us what rule 5 is. It's almost certainly going to be a Default-Deny rule, which means you're missing a firewall rule somewhere. Do you have a rule allowing all protocols from OPT1 to LAN? -- -Adam Thompson athom...@athompso.net ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Disable antispoofing on an interface
Sorry fat fingered the reply. Is there something on the other end of the Ping to answer? Yudhvir On Jul 17, 2014, at 7:11 PM, Mehmasarja Darks mehmasa...@gmail.com wrote: That block is on a TCP packet, not UDP. Also, is there something on the othersid Yudhvir On Jul 17, 2014, at 4:26 PM, Adam Thompson athom...@athompso.net wrote: On 14-07-17 12:32 PM, NetSys Pro wrote: Here's the output: Jul 17 21:27:50 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 0, length 64 Jul 17 21:27:52 fw2 pf: 00:00:01.885014 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 1, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:52 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 2, length 64 Jul 17 21:27:52 fw2 pf: 00:00:00.358395 rule 5/0(match): block in on re2: (tos 0x0, ttl 128, id 1110, offset 0, flags [DF], proto TCP (6), length 40) Jul 17 21:27:52 fw2 pf: 192.168.6.106.54118 23.214.64.109.443: Flags [R.], cksum 0x4fe4 (correct), seq 1951833685, ack 1897326514, win 0, length 0 Jul 17 21:27:53 fw2 pf: 00:00:00.628387 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 2, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:53 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 3, length 64 Jul 17 21:27:54 fw2 pf: 00:00:01.148349 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 3, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:54 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 4, length 64 Jul 17 21:27:55 fw2 pf: 00:00:00.874917 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 4, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:55 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 5, length 64 Jul 17 21:27:56 fw2 pf: 00:00:01.011050 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 5, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:56 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 6, length 64 Jul 17 21:27:57 fw2 pf: 00:00:00.989951 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 6, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:57 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 7, length 64 Jul 17 21:27:58 fw2 pf: 00:00:00.995826 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 7, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:58 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 8, length 64 Jul 17 21:27:59 fw2 pf: 00:00:01.031938 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 8, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:27:59 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 9, length 64 Jul 17 21:28:00 fw2 pf: 00:00:00.971443 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 9, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:28:00 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 10, length 64 Jul 17 21:28:01 fw2 pf: 00:00:01.040452 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 10, offset 0, flags [none], proto ICMP (1), length 84) Jul 17 21:28:01 fw2 pf: 10.6.2.10 192.168.6.106: ICMP echo request, id 43547, seq 11, length 64 What do you think? Since there's only one block in that list, I'm going to speculate that it represents your missing packet. Also, it refers to re2 which is likely your OPT1 interface if you did things conventionally. I don't know what rule 5 is, although anything with that low a # is likely to be a system-generated rule. On my system, it's the Default deny rule IPv6, although that doesn't sound likely in your case. You'll want to run pfctl -vv -s rules | more and tell us what rule 5 is. It's almost certainly going to be a Default-Deny rule, which means you're missing a firewall rule somewhere. Do you have a rule allowing all protocols from OPT1 to LAN? -- -Adam Thompson athom...@athompso.net ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
I second nixing the thread. pfSense does not benefit from this. Mehma On Oct 11, 2013, at 3:40 PM, Jim Thompson j...@netgate.com wrote: On Oct 11, 2013, at 12:39, Thinker Rix thinke...@rocketmail.com wrote: Again: The real threat by my comprehension is not some guy in the internet trying to place malicious code into the code base, but simply and plainly some NSA officers knock the door an force the project leaders to do it. Please cite the law they might use to so this. Hint: it doesn't exist. Hint 2: if you think Lavabit applies, you're part of the problem. Otherwise: get off my lawn. I'm willing to listen to: I've dreamed up this possible attack that could inject bad code into pfSense. And especially, I think I've found a problem. I'm not willing to endure this uninformed Alex Jonesian crapfest. Now that I'm back on US soil, I promise that if the later continues, I will kill the thread. People who hijack threads will be dealt with. I simply don't have time for it, and the people who actually work on pfSense don't gave time for it. Nor will I endure the besmirching of pfSense's good name and trademark. If you have real issues, or even theories supported by minimal evidence, bring them forward. Otherwise: STFU. Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
