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? Subject: RE: [pfSense] Disable antispoofing on an interface From: [email protected] Date: Thu, 17 Jul 2014 12:23:18 -0500 To: [email protected]; [email protected] If you run (from memory, here!) "clog -f /var/log/filter.log" while the packet is arriving, you should see what rule is blocking it. You may want to set up a capture in your terminal emulator, as there will likely be a lot of unrelated output and it'll scroll off-screen quickly. -Adam On July 17, 2014 12:20:10 PM CDT, NetSys Pro <[email protected]> wrote: I just did a tcpdump on pfSense and I do see the ICMP request coming in on the OPT1 interface.So, this means that the WANOPT appliance is not the culprit. Subject: RE: [pfSense] Disable antispoofing on an interface From: [email protected] Date: Thu, 17 Jul 2014 12:10:44 -0500 To: [email protected]; [email protected] Not really possible. If tcpdump cann't show you the packet, then the problem is occurring before pfSense... i.e. in the WAN optimizer. On July 17, 2014 12:01:12 PM CDT, NetSys Pro <[email protected]> wrote: Adam, Thanks for your reply.First of all, as I said before, I had already posted the same question on the forum and had not received any reply.However, Chris BUECHLER replied to my posts about 2 days ago.If it is better that I stop the cross-posting, then someone please do advise.Until then, we'll continue on both the forum and here in the mailing list.Of course, I will update both with the findings. So, regarding your question, from the log (see screenshot on the forum) on the remote pfSense, I see that the ICMP request is ALLOWed into the remote OPT1 (aka SILVERPEAK) interface.However, after doing packet captures on the other interfaces, I do not see the packet coming out anywhere!So, I suppose the packet is being silently dropped. Is that possible? Subject: RE: [pfSense] Disable antispoofing on an interface From: [email protected] Date: Thu, 17 Jul 2014 10:50:27 -0500 To: [email protected]; [email protected] How do you know pfSense is dropping the packet? Does it show up in a packet capture on OPT1? -Adam On July 17, 2014 5:12:07 AM CDT, NetSys Pro <[email protected]> wrote: Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: [email protected] Date: Mon, 14 Jul 2014 20:24:36 -0500 To: [email protected]; [email protected] I suspect you need to be looking not for anti-spoofing but for anti-bogon rules. Can't remember what pfSense calls it offhand. -Adam On July 14, 2014 6:19:22 PM CDT, NetSys Pro <[email protected]> wrote: Hello everyone, First of all, please note that I have already posted the question below on the pfSense forum (see https://forum.pfsense.org/index.php?topic=79081.0) since about 1 week without any reply. Given the urgency of the matter, I decided to post to the mailing list, hoping for some here. BTW: I don't know if this will be of any help to obtain a reply, please note that I have a Gold membership subscription as well. So, regarding my question, I'll copy/paste from the forum as follows: I have 2 pfSense boxes (both version 2.1.4) connected via the Internet. Each one has 3 interfaces: LAN, WAN & OPT1. There is an IPsec VPN between the 2 pfSense boxes. A WAN optimisation (we'll call it WANOPT) appliance is connected to the OPT1 interface on each side. There is a UDP tunnel between the 2 WANOPT appliances. This UDP tunnel goes inside the IPsec tunnel. I use PBR (as a LAN rule) to redirect traffic going to the remote LAN into the WANOPT appliance. This is what I've observed after starting to ping a remote LAN machine from a local LAN machine: 1. On reaching the local LAN interface, the ICMP echo request is properly redirected to the WANOPT appliance. 2. The ICMP request then goes inside the UDP tunnel. 3. The UDP packets go into the IPsec tunnel. 4. On the remote side, a tcpdump shows that the ICMP packet does come out of the WANOPT appliance and therefore the UDP tunnel. 5. It then reaches the OPT1 interface of the remote firewall. 6. However, it does NOT come out any interface!!! 7. I have an "Allow all protocols from any to any" rule on both the IPsec and OPT1 interfaces, for testing purposes. 8. There's nothing in the log saying that the packet was dropped. In fact, there's a log entry which says that the packet was actually allowed into the OPT1 interface! What has happened to the packet? NB: 1. On the remote side, when the ICMP packet comes out of the UDP tunnel, its source IP is that of the local LAN machine and its destination is that of the remote LAN machine. 2. Is this packet being considered a spoofed packet? I modified the file /etc/inc/filter.inc (around line 3105 in pfSense 2.1.4) to disable antispoofing on the OPT1 interface and rebooted both firewalls without any success. I confirmed that the file /tmp/rules.debug did not contain the antispoof directive for the OPT1 interface after reboot. RFC 1918 private IP addresses are not being blocked either. Thank you for any help. List mailing list [email protected] https://lists.pfsense.org/mailman/listinfo/list -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________ List mailing list [email protected] https://lists.pfsense.org/mailman/listinfo/list
