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 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 Thom
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 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
>> 4354
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),
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 th
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
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
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...@li
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 wrote:
>Adam,
>Thanks for your reply.First of all, as I said before, I had already
>posted the same question on the
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'
On Thu, Jul 17, 2014 at 1:25 PM, Moshe Katz wrote:
> On Thu, Jul 17, 2014 at 12:13 PM, Dean Landry
> 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 cor
On Thu, Jul 17, 2014 at 12:13 PM, Dean Landry 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 th
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?
Th
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 wrote:
>Hello Adam,Anything else I could try?
>Thanks
>
>Subject: Re: [pfSense] Disable antispoofing on an interface
>From: athom...@athompso.net
>Date:
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 t
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
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 diff
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
17 matches
Mail list logo
