Re: [pfSense] Disable antispoofing on an interface
Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: athom...@athompso.net Date: Mon, 14 Jul 2014 20:24:36 -0500 To: list@lists.pfsense.org; netsys...@live.com 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 netsys...@live.com 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Disable antispoofing on an interface
Post your logs. Is this behavior the same from either LAN? Is this setup virgin, meaning did it work with older pfSense versions and is now misbehaving or is this a fresh setup? Obviously the IPsec/UDP link should be simplified and tested to isolate the problem. You can also test the setup on different hardware. Is the current system on VMs? I'm no expert - you've probably tried all this, so let us know how that went. ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.1 + Squid3 + SquidGuard redirect
The first thing you can check is whether the error is being introduced in
SquidGuard itself or later in the stack.
Run /usr/pbi/squidguard-squid3-amd64/bin/squidGuard -c
/usr/pbi/squidguard-squid3-amd64/etc/squidGuard/squidGuard.conf in a shell
(console or SSH) and pass those URLs to it to see the raw output that
SquidGuard is sending back. If they are correct there, then you can narrow
down the problem to Squid or something else in pfSense. If you get the
wrong URLs in the she'll output, them it's something with your SquidGuard
configuration.
I don't see anything offhand with either configuration that looks wrong, so
this will tell you where to focus.
Moshe
(On a mobile device - sorry for top-posting.)
On Jul 17, 2014 8:54 AM, Dean Landry land...@kingswood.edu wrote:
Hello,
We have configured pfSense with Squid3 and SquidGuard in order to do
content filtering. We have blocked several categories and also have a set
of manually blocked URLs. If I attempt to go to a manually blocked URL, I
am correctly redirected to the sgerror page:
https://10.10.10.1/sgerror.php?url=403%20a=10.0.0.100n=i=s=defaultt=Manual_Blacklistu=http://eztv.it/
However when I go to a page blocked by a category, it doesn't give the
correct redirect link (resulting in a 404 error):
https://10.10.10.1/sgerror.phpa=10.0.0.100n=i=s=defaultt=blk_blacklists_adultu=http://sex.com/
It is stripping the ?url=403%20 which breaks the link.
Looking at the filter config, it seems odd that the redirect URLs are
http on port 443. The resulting page is https without the port indicated.
Here is my Filter config:
#
# SquidGuard configuration file
# This file generated automaticly with SquidGuard configurator
# (C)2006 Serg Dvoriancev
# email: dv_s...@mail.ru
#
logdir /var/squidGuard/log
dbhome /var/db/squidGuard
# Sites to block (not handled by blacklist service)
dest Manual_Blacklist {
domainlist Manual_Blacklist/domains
expressionlist Manual_Blacklist/expressions
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
log block.log
}
# Sites to allow (not handled by blacklist service)
dest ManualWhitelist {
domainlist ManualWhitelist/domains
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
log block.log
}
#
rew safesearch {
s@(google..*/search?.*q=.*)@ safe=active@i
s@(google..*/images.*q=.*)@ safe=active@i
s@(google..*/groups.*q=.*)@ safe=active@i
s@(google..*/news.*q=.*)@ safe=active@i
s@(yandex..*/yandsearch?.*text=.*)@ fyandex=1@i
s@(search.yahoo..*/search.*p=.*)@ vm=rv=1@i
s@(search.live..*/.*q=.*)@ adlt=strict@i
s@(search.msn..*/.*q=.*)@ adlt=strict@i
s@(.bing..*/.*q=.*)@ adlt=strict@i
log block.log
}
#
acl {
#
default {
pass ManualWhitelist !Manual_Blacklist !blk_blacklists_abortion
!blk_blacklists_ads !blk_blacklists_adult !blk_blacklists_antispyware
!blk_blacklists_artnudes !blk_blacklists_filesharing
!blk_blacklists_gambling !blk_blacklists_hacking !blk_blacklists_lingerie
!blk_blacklists_malware !blk_blacklists_mixed_adult
!blk_blacklists_naturism !blk_blacklists_phishing !blk_blacklists_porn
!blk_blacklists_proxy !blk_blacklists_sexuality
!blk_blacklists_sexualityeducation !blk_blacklists_spyware
!blk_blacklists_tobacco !blk_blacklists_violence
!blk_blacklists_virusinfected !blk_blacklists_warez !blk_blacklists_weapons
blk_blacklists_audio-video blk_blacklists_news all
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
rewrite safesearch
log block.log
}
}
And here is my Proxy Config:
# This file is automatically generated by pfSense
# Do not edit manually !
http_port 10.0.0.1:3128
http_port 127.0.0.1:3128 intercept
icp_port 7
dns_v4_first off
pid_filename /var/run/squid.pid
cache_effective_user proxy
cache_effective_group proxy
error_default_language en
icon_directory /usr/pbi/squid-amd64/etc/squid/icons
visible_hostname localhost
cache_mgr w...@beulahcamp.com
access_log /var/squid/logs/access.log
cache_log /var/squid/logs/cache.log
cache_store_log none
sslcrtd_children 0
logfile_rotate 7
shutdown_lifetime 3 seconds
# Allow local network(s) on interface(s)
acl localnet src 10.0.0.0/16
uri_whitespace strip
acl dynamic urlpath_regex cgi-bin ?
cache deny dynamic
cache_mem 8 MB
maximum_object_size_in_memory 256 KB
memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA
cache_dir ufs /var/squid/cache 1024 16 256
minimum_object_size 0 KB
maximum_object_size 4 KB
offline_mode offcache_swap_low 90
cache_swap_high 95
# No redirector configured
#Remote proxies
# Setup some default acls
acl allsrc src all
acl localhost src 127.0.0.1/32
acl safeports port 21 70 80 210 280 443 488 563 591 631 777 901 443 3128
1025-65535 1935
acl sslports port 443 563 443 1935
acl manager proto
Re: [pfSense] Disable antispoofing on an interface
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 netsys...@live.com wrote: Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: athom...@athompso.net Date: Mon, 14 Jul 2014 20:24:36 -0500 To: list@lists.pfsense.org; netsys...@live.com 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 netsys...@live.com 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.1 + Squid3 + SquidGuard redirect
Thanks Moshe,
I've run squidGuard via ssh as suggested and get the correct URL. So it's
something other than SquidGuard. I noticed that any new URLs I try seem to
be correctly redirected. Could it be that Squid itself is caching the
response from when my configuration was previously broken?
Thanks,
Dean
On Thu, Jul 17, 2014 at 12:00 PM, Moshe Katz mo...@ymkatz.net wrote:
The first thing you can check is whether the error is being introduced in
SquidGuard itself or later in the stack.
Run /usr/pbi/squidguard-squid3-amd64/bin/squidGuard -c
/usr/pbi/squidguard-squid3-amd64/etc/squidGuard/squidGuard.conf in a shell
(console or SSH) and pass those URLs to it to see the raw output that
SquidGuard is sending back. If they are correct there, then you can narrow
down the problem to Squid or something else in pfSense. If you get the
wrong URLs in the she'll output, them it's something with your SquidGuard
configuration.
I don't see anything offhand with either configuration that looks wrong,
so this will tell you where to focus.
Moshe
(On a mobile device - sorry for top-posting.)
On Jul 17, 2014 8:54 AM, Dean Landry land...@kingswood.edu wrote:
Hello,
We have configured pfSense with Squid3 and SquidGuard in order to do
content filtering. We have blocked several categories and also have a set
of manually blocked URLs. If I attempt to go to a manually blocked URL, I
am correctly redirected to the sgerror page:
https://10.10.10.1/sgerror.php?url=403%20a=10.0.0.100n=i=s=defaultt=Manual_Blacklistu=http://eztv.it/
However when I go to a page blocked by a category, it doesn't give the
correct redirect link (resulting in a 404 error):
https://10.10.10.1/sgerror.phpa=10.0.0.100n=i=s=defaultt=blk_blacklists_adultu=http://sex.com/
It is stripping the ?url=403%20 which breaks the link.
Looking at the filter config, it seems odd that the redirect URLs are
http on port 443. The resulting page is https without the port indicated.
Here is my Filter config:
#
# SquidGuard configuration file
# This file generated automaticly with SquidGuard configurator
# (C)2006 Serg Dvoriancev
# email: dv_s...@mail.ru
#
logdir /var/squidGuard/log
dbhome /var/db/squidGuard
# Sites to block (not handled by blacklist service)
dest Manual_Blacklist {
domainlist Manual_Blacklist/domains
expressionlist Manual_Blacklist/expressions
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
log block.log
}
# Sites to allow (not handled by blacklist service)
dest ManualWhitelist {
domainlist ManualWhitelist/domains
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
log block.log
}
#
rew safesearch {
s@(google..*/search?.*q=.*)@ safe=active@i
s@(google..*/images.*q=.*)@ safe=active@i
s@(google..*/groups.*q=.*)@ safe=active@i
s@(google..*/news.*q=.*)@ safe=active@i
s@(yandex..*/yandsearch?.*text=.*)@ fyandex=1@i
s@(search.yahoo..*/search.*p=.*)@ vm=rv=1@i
s@(search.live..*/.*q=.*)@ adlt=strict@i
s@(search.msn..*/.*q=.*)@ adlt=strict@i
s@(.bing..*/.*q=.*)@ adlt=strict@i
log block.log
}
#
acl {
#
default {
pass ManualWhitelist !Manual_Blacklist !blk_blacklists_abortion
!blk_blacklists_ads !blk_blacklists_adult !blk_blacklists_antispyware
!blk_blacklists_artnudes !blk_blacklists_filesharing
!blk_blacklists_gambling !blk_blacklists_hacking !blk_blacklists_lingerie
!blk_blacklists_malware !blk_blacklists_mixed_adult
!blk_blacklists_naturism !blk_blacklists_phishing !blk_blacklists_porn
!blk_blacklists_proxy !blk_blacklists_sexuality
!blk_blacklists_sexualityeducation !blk_blacklists_spyware
!blk_blacklists_tobacco !blk_blacklists_violence
!blk_blacklists_virusinfected !blk_blacklists_warez !blk_blacklists_weapons
blk_blacklists_audio-video blk_blacklists_news all
redirect
http://10.10.10.1:443/sgerror.php?url=403%20a=%an=%ni=%is=%st=%tu=%u
rewrite safesearch
log block.log
}
}
And here is my Proxy Config:
# This file is automatically generated by pfSense
# Do not edit manually !
http_port 10.0.0.1:3128
http_port 127.0.0.1:3128 intercept
icp_port 7
dns_v4_first off
pid_filename /var/run/squid.pid
cache_effective_user proxy
cache_effective_group proxy
error_default_language en
icon_directory /usr/pbi/squid-amd64/etc/squid/icons
visible_hostname localhost
cache_mgr w...@beulahcamp.com
access_log /var/squid/logs/access.log
cache_log /var/squid/logs/cache.log
cache_store_log none
sslcrtd_children 0
logfile_rotate 7
shutdown_lifetime 3 seconds
# Allow local network(s) on interface(s)
acl localnet src 10.0.0.0/16
uri_whitespace strip
acl dynamic urlpath_regex cgi-bin ?
cache deny dynamic
cache_mem 8 MB
maximum_object_size_in_memory 256 KB
memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA
cache_dir ufs /var/squid/cache 1024
Re: [pfSense] pfSense 2.1 + Squid3 + SquidGuard redirect
On Thu, Jul 17, 2014 at 12:13 PM, Dean Landry land...@kingswood.edu wrote: Thanks Moshe, I've run squidGuard via ssh as suggested and get the correct URL. So it's something other than SquidGuard. I noticed that any new URLs I try seem to be correctly redirected. Could it be that Squid itself is caching the response from when my configuration was previously broken? Thanks, Dean On Thu, Jul 17, 2014 at 12:00 PM, Moshe Katz mo...@ymkatz.net wrote: The first thing you can check is whether the error is being introduced in SquidGuard itself or later in the stack. Run /usr/pbi/squidguard-squid3-amd64/bin/squidGuard -c /usr/pbi/squidguard-squid3-amd64/etc/squidGuard/squidGuard.conf in a shell (console or SSH) and pass those URLs to it to see the raw output that SquidGuard is sending back. If they are correct there, then you can narrow down the problem to Squid or something else in pfSense. If you get the wrong URLs in the she'll output, them it's something with your SquidGuard configuration. I don't see anything offhand with either configuration that looks wrong, so this will tell you where to focus. Moshe (On a mobile device - sorry for top-posting.) On Jul 17, 2014 8:54 AM, Dean Landry land...@kingswood.edu wrote: Hello, We have configured pfSense with Squid3 and SquidGuard in order to do content filtering. We have blocked several categories and also have a set of manually blocked URLs. If I attempt to go to a manually blocked URL, I am correctly redirected to the sgerror page: https://10.10.10.1/sgerror.php?url=403%20a=10.0.0.100n=i=s=defaultt=Manual_Blacklistu=http://eztv.it/ However when I go to a page blocked by a category, it doesn't give the correct redirect link (resulting in a 404 error): https://10.10.10.1/sgerror.phpa=10.0.0.100n=i=s=defaultt=blk_blacklists_adultu=http://sex.com/ It is stripping the ?url=403%20 which breaks the link. Looking at the filter config, it seems odd that the redirect URLs are http on port 443. The resulting page is https without the port indicated. Here is my Filter config: [SNIP] And here is my Proxy Config: [SNIP] cache_dir ufs /var/squid/cache 1024 16 256 I've tried uninstalling and reinstalling the squidGuard package, but I don't think that reset any options to fix anything. Can someone recommend where to start troubleshooting this? Thanks, Dean Dean, Given that Squid is first and foremost a caching system, I would guess that it does cache the SquidGuard results. I don't know for sure though, but there's an easy way to check - look at the /var/squidGuard/log/block.log file and see how many times the requests show up. If they don't show up as many times as you did them, or if you do new requests and you get redirected but they don't show up in the log, then Squid is obviously caching the results. Moshe -- Moshe Katz -- mo...@ymkatz.net -- +1(301)867-3732 ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.1 + Squid3 + SquidGuard redirect
On Thu, Jul 17, 2014 at 1:25 PM, Moshe Katz mo...@ymkatz.net wrote: On Thu, Jul 17, 2014 at 12:13 PM, Dean Landry land...@kingswood.edu wrote: Thanks Moshe, I've run squidGuard via ssh as suggested and get the correct URL. So it's something other than SquidGuard. I noticed that any new URLs I try seem to be correctly redirected. Could it be that Squid itself is caching the response from when my configuration was previously broken? Thanks, Dean On Thu, Jul 17, 2014 at 12:00 PM, Moshe Katz mo...@ymkatz.net wrote: Dean, Given that Squid is first and foremost a caching system, I would guess that it does cache the SquidGuard results. I don't know for sure though, but there's an easy way to check - look at the /var/squidGuard/log/block.log file and see how many times the requests show up. If they don't show up as many times as you did them, or if you do new requests and you get redirected but they don't show up in the log, then Squid is obviously caching the results. Moshe The broken requests aren't in block.log. Does anyone know how to prevent squid for caching the squidguard responses? ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Disable antispoofing on an interface
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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 10:50:27 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com wrote: Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: athom...@athompso.net Date: Mon, 14 Jul 2014 20:24:36 -0500 To: list@lists.pfsense.org; netsys...@live.com 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 netsys...@live.com 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Disable antispoofing on an interface
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: athom...@athompso.net Date: Thu, 17 Jul 2014 12:10:44 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 10:50:27 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com wrote: Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: athom...@athompso.net Date: Mon, 14 Jul 2014 20:24:36 -0500 To: list@lists.pfsense.org; netsys...@live.com 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 netsys...@live.com 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list -- Sent from my Android device with K-9 Mail. Please
Re: [pfSense] Disable antispoofing on an interface
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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 12:10:44 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 10:50:27 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com wrote: Hello Adam,Anything else I could try? Thanks Subject: Re: [pfSense] Disable antispoofing on an interface From: athom...@athompso.net Date: Mon, 14 Jul 2014 20:24:36 -0500 To: list@lists.pfsense.org; netsys...@live.com 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 netsys...@live.com 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
Re: [pfSense] Disable antispoofing on an interface
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: athom...@athompso.net Date: Thu, 17 Jul 2014 12:23:18 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 12:10:44 -0500 To: netsys...@live.com; list@lists.pfsense.org 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 netsys...@live.com 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: athom...@athompso.net Date: Thu, 17 Jul 2014 10:50:27 -0500 To: netsys...@live.com; list@lists.pfsense.org How do you know pfSense is dropping the
Re: [pfSense] Squid Problem and DNS?
On 2014-07-16 08:43, Brian Caouette wrote: I have not tried ISP's dns as I've found Googles to be faster. I can try that test tonight when I get home though to rule out the possibility. Be aware that using non-local DNS can end up with a suboptimal CDN routing situation as you get routed to the CDN nearest your chosen DNS servers rather than your actual local network. These might well be appropriately placed, but they might not, depending on where Google's DNS resolution happens for the node that you hit. In my opinion, running your own DNS is a better solution, if you're technically capable. On pfSense, this is often as simple as installing unbound and using it as a full resolver instead of DNS Forwarding/dnsmasq. As for #2 I understand I just find it odd the prior install although poor hit rate still produce results were the current install is at 0 after a week. Our traffic hasn't changed we still surf the same sites. The kids are typically on facebook, youtube, and game sites and the wife on school and work as I am. Between sites moving everything to HTTPS and the amount of dynamic content, hit rates are typically very low these days. Even static resources are often served over HTTPS (SPDY removing the last major reason to not use HTTPS for such things) Making it worse (but not really) is the way a lot of static content is called, embedding version numbers into JS/CSS/etc file names and using cache control headers to encourage clients to cache these resources for weeks, allowing browsers to efficiently cache resources that used to be served out of local proxy servers. Still, I'd expect a rate greater than absolute 0, but it takes a large number of users to get any real value out of a proxy level cache these days. Or at least that was my experience when our office was stuck on a 3Mb pipe instead of our usual dual 100Mb for a few months. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Disable antispoofing on an interface
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
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
