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 <[email protected]> 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 <[email protected]> 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
>>  [email protected]
>> _______________________________________________
>> List mailing list
>> [email protected]
>> https://lists.pfsense.org/mailman/listinfo/list
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list

Reply via email to