Re: [pfSense] DMZ not working since upgrade 2.3

[PiBa]

Hi Jean-Laurent,

Op 25-6-2016 om 18:46 schreef Jean-Laurent Ivars:

You’re perfectly right i only gave extracts of the logs :) next time I’m going 
to be more precise and make the capture from the beginning...
Its not that extracts are bad, just knowing what part to extract to make 
it easier to compare on 1 screen.
I cut your tcpdumps a bit shorter below after a few packets ;) should 
still have all relevant info for the current issue, if anyone else wants 
to go over them.

Anyway, as you suppose, I continue to see the same [S] paquet repeating again 
and again…
The client tries to connect, but never gets the [S.] reply packet. As 
such its does the right thing to try again a few times..

These captures have been done directly on a WAN interface (not on the LAN one) 
the reason you see a private address is because there is a double NAT...
Double nat is in general a bad thing. I assumed LAN because of private 
ip's.. Anyway are all locations home/business connections where you 
physically manage the router that connects to the isp? Not like inside a 
OVH datacenter.? (i know OVH does some strange things in the DC..) Just 
for ruling some problem in them out you've tried restarting all those 
router/modem devices? Might not help at all, if it does whel that would 
indicate a issue there..
Also i assume all the pfSense boxes can properly use the internet 
themselves without any issue?

As you ask, I am going to send you :

- tcpdump on a client for the port 2223
- tcpdump on the pfsense on the port 2223 choosing the interface that is 
directly connected to the modem-router

1- From the pfsense WAN interface point of view with a not working gateway from 
the begining until the end (time out from the client side) :

[2.3.1-RELEASE][r...@pfsense.concorde-pereire.loc]/root: tcpdump -i re0 port 
2223
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:01:51.206180 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333778453 ecr 0,sackOK,eol], length 0
18:01:51.206358 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333778453], length 0
18:01:52.214077 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333779453 ecr 0,sackOK,eol], length 0
18:01:52.214177 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333779453], length 0
The question is where/why does this reply [S.] packet get dropped 
between pfsense and client machine.

Can you try above tcpdump 1. again with -en flags?

*tcpdump -en -i re0 port 2223 *

Only 4 packets should be enough.. Basically for checking if 
source/destination MAC addresses are the same..



2- From the client point of view to the not working gateway from the begining 
until the end (time out from the client side) :

root@MacBook-de-Jean-Laurent:~$ tcpdump -i en0 port 2223
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:01:51.196869 IP 192.168.10.50.51548 > 
20-98-190-109.dsl.ovh.fr.rockwell-csp3: Flags [S], seq 3384870708, win 65535, 
options [mss 1460,nop,wscale 5,nop,nop,TS val 333778453 ecr 0,sackOK,eol], length 0
18:01:52.206194 IP 192.168.10.50.51548 > 
20-98-190-109.dsl.ovh.fr.rockwell-csp3: Flags [S], seq 3384870708, win 65535, 
options [mss 1460,nop,wscale 5,nop,nop,TS val 333779453 ecr 0,sackOK,eol], length 0
Client never gets the response packets.. As such keeps trying again for 
a while.

3- From the pfsense WAN interface point of view with a working gateway from the 
begining until the end (connexion then a few commands and deconnexion) :

[2.3.1-RELEASE][r...@pfsense.concorde-pereire.loc]/root: tcpdump -i re0 port 
2223
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:09:12.648018 IP 196.222.21.93.rev.sfr.net.51615 > 192.168.101.254.2223: 
Flags [S], seq 4029864830, win 65535, options [mss 1460,wscale 6,sackOK,eol], 
length 0
18:09:12.648159 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51615: 
Flags [S.], seq 2831647839, ack 4029864831, win 65228, options [mss 
1460,nop,wscale 7,sackOK,eol], length 0
18:09:12.687456 IP 196.222.21.93.rev.sfr.net.51615 > 192.168.101.254.2223: 
Flags [.], ack 1, win 8192, length 0
18:09:12.687607 IP 196.222.21.93.rev.sfr.net.51615 > 192.168.101.254.2223: 
Flags [P.], seq 1:22, ack 1, win 8192, length 21
18:09:12.687653 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51615: 
Flags [.], ack 22, win 

Re: [pfSense] DMZ not working since upgrade 2.3

[Jean-Laurent Ivars]

Hi Piba, (and other people)

Thank you very much for your answer !

You’re perfectly right i only gave extracts of the logs :) next time I’m going 
to be more precise and make the capture from the beginning...
Anyway, as you suppose, I continue to see the same [S] paquet repeating again 
and again…

These captures have been done directly on a WAN interface (not on the LAN one) 
the reason you see a private address is because there is a double NAT...

As you ask, I am going to send you :

- tcpdump on a client for the port 2223
- tcpdump on the pfsense on the port 2223 choosing the interface that is 
directly connected to the modem-router

1- From the pfsense WAN interface point of view with a not working gateway from 
the begining until the end (time out from the client side) :

[2.3.1-RELEASE][r...@pfsense.concorde-pereire.loc]/root: tcpdump -i re0 port 
2223 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:01:51.206180 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333778453 ecr 0,sackOK,eol], length 0
18:01:51.206358 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333778453], length 0
18:01:52.214077 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333779453 ecr 0,sackOK,eol], length 0
18:01:52.214177 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333779453], length 0
18:01:53.218322 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333780453 ecr 0,sackOK,eol], length 0
18:01:53.218431 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333780453], length 0
18:01:54.222440 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333781453 ecr 0,sackOK,eol], length 0
18:01:54.222547 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333781453], length 0
18:01:55.222574 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333782453 ecr 0,sackOK,eol], length 0
18:01:55.222688 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333782453], length 0
18:01:56.224698 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333783453 ecr 0,sackOK,eol], length 0
18:01:56.224785 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333783453], length 0
18:01:58.234946 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333785453 ecr 0,sackOK,eol], length 0
18:01:58.235056 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333785453], length 0
18:02:01.234194 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333785453], length 0
18:02:02.253723 IP 196.222.21.93.rev.sfr.net.51548 > 192.168.101.254.2223: 
Flags [S], seq 3384870708, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS 
val 333789453 ecr 0,sackOK,eol], length 0
18:02:02.253832 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333789453], length 0
18:02:05.25 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333789453], length 0
18:02:08.253228 IP 192.168.101.254.2223 > 196.222.21.93.rev.sfr.net.51548: 
Flags [S.], seq 2254053748, ack 3384870709, win 65228, options [mss 
1460,nop,wscale 7,sackOK,TS val 1269164786 ecr 333789453], length 0
18:02:10.470731 IP 

Re: [pfSense] DMZ not working since upgrade 2.3

[PiBa]

Hi Jean-Laurent,

Op 25-6-2016 om 10:37 schreef Jean-Laurent Ivars:

This is logs generated by tcpdump from the same client machine when I try to 
access the firewall thru working internet access provider :

port 2223
16:55:04.501509 IP 46.105.230.225.39304 > 192.168.101.254.2223: Flags [P.], seq 
29:701, ack 22, win 32844, length 672
16:55:04.501652 IP 192.168.101.254.2223 > 46.105.230.225.39304: Flags [P.], seq 
22:910, ack 701, win 508, length 888
port 1
16:58:51.821691 IP 192.168.101.254.1 > 46.105.230.225.5829: Flags [P.], seq 
209411:210119, ack 2393, win 513, length 708
16:58:52.058014 IP 46.105.230.225.5829 > 192.168.101.254.1: Flags [.], ack 
210119, win 32673, length 0
Both these captures are in the 'middle' of a already working connection, 
but does show it 'works' at that time.. To compare it to the capture 
below better start capturing before initiation the connection :) .

And there the same command output when I try to access from one that is not 
working :

Port 2223
16:53:13.240166 IP 46.105.230.225.19480 > 192.168.101.254.2223: Flags [S], seq 
3864438539, win 8192, options [mss 1460,nop,nop,sackOK], length 0
16:53:13.240306 IP 192.168.101.254.2223 > 46.105.230.225.19480: Flags [S.], seq 
2492220538, ack 3864438540, win 65228, options [mss 1460,nop,wscale 7,sackOK,eol], 
length 0
Port 1
16:56:39.864021 IP 46.105.230.225.41932 > 192.168.101.254.1: Flags [S], seq 
2837326484, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
16:56:39.864169 IP 192.168.101.254.1 > 46.105.230.225.41932: Flags [S.], 
seq 1993261464, ack 2837326485, win 65228, options [mss 1460,nop,wscale 
7,sackOK,eol], length 0
These SYN [S] and SYN-ACK [S.] packets are the normal start of a tcp 
connection. Sofar nothing strange during connection initiation, there 
should follow a 3rd ACK [.] packet after which there would follow some 
useful data exchange like in the first working captures.. But i guess 
you keep seeing these same two [S] and [S.] packets repeating.?
You have performed these captures on the LAN interface, could you repeat 
them on the WAN interface to confirm that the [S.] is properly send back 
on that same interface the client send the request on? Also if its 
possible to capture on the client device it would be interesting to see 
if the [S.] arrives there properly.

I use pcengine APU system, the model is AMD G-T40E Processor with 3 NIC ( I 
believe It could be something related to a NIC setting somewhere but really 
don’t know)

Is someone encounter the same issue than me ? maybe it’s just a setting in the 
NIC driver ?

I don't expect it to be hardware/driver related at this moment..

Do you have any packages installed? Snort or Suricata can sometimes 
unexpectedly block traffic you do want.. Or other configurations like 
limiters/shapers or openvpn/ipsec networks can possibly interfere..


Regards,
PiBa-NL
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] DMZ not working since upgrade 2.3

[Jean-Laurent Ivars]

Dear list,

I apologie if the subject have already been treated…

Since the upgrade to the new version I have issue to access to the pfsense from 
the outside from certain internet providers, before the upgrade it was working 
correctly and since the update the port forwarding (or DMZ setting) is not 
working anymore…

I made verification that there is no firewall rule that block traffic but it 
was working before... (I even allowed everything during time of testing) and I 
think there is not but the pfsense is not anymore responding correctly from the 
outside.

I have this issue with 2 different installations and different providers, I am 
from France and with Orange business DMZ I have no issue but with OVH or FREE, 
the redirection it’s not working anymore (I even try putting the modem in 
bridge mode, the pfsense box obtains the wan IP no problem there but it changes 
nothing) 
What is weird is that with some others providers it works (Orange and SFR)

That being, the firewall is perfectly capable to use these connexions to 
provide internet access so I think the connectivity is not the matter then I 
tried to analyse the traffic with tcpdump and I can see a difference between 
when I use a working and a not working provider but I have not the skill to 
understand what the tcpdump tells, I don’t understand what happens here, I only 
can see there a rapport with length witch is 0 when the connexion is not 
working and also the is some options informations…

I tried with port 1 (I use for web interface) and 2223 (I use for ssh 
access)

This is logs generated by tcpdump from the same client machine when I try to 
access the firewall thru working internet access provider :

port 2223
16:55:04.501509 IP 46.105.230.225.39304 > 192.168.101.254.2223: Flags [P.], seq 
29:701, ack 22, win 32844, length 672
16:55:04.501652 IP 192.168.101.254.2223 > 46.105.230.225.39304: Flags [P.], seq 
22:910, ack 701, win 508, length 888
port 1
16:58:51.821691 IP 192.168.101.254.1 > 46.105.230.225.5829: Flags [P.], seq 
209411:210119, ack 2393, win 513, length 708
16:58:52.058014 IP 46.105.230.225.5829 > 192.168.101.254.1: Flags [.], ack 
210119, win 32673, length 0

And there the same command output when I try to access from one that is not 
working :

Port 2223
16:53:13.240166 IP 46.105.230.225.19480 > 192.168.101.254.2223: Flags [S], seq 
3864438539, win 8192, options [mss 1460,nop,nop,sackOK], length 0
16:53:13.240306 IP 192.168.101.254.2223 > 46.105.230.225.19480: Flags [S.], seq 
2492220538, ack 3864438540, win 65228, options [mss 1460,nop,wscale 
7,sackOK,eol], length 0
Port 1
16:56:39.864021 IP 46.105.230.225.41932 > 192.168.101.254.1: Flags [S], seq 
2837326484, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
16:56:39.864169 IP 192.168.101.254.1 > 46.105.230.225.41932: Flags [S.], 
seq 1993261464, ack 2837326485, win 65228, options [mss 1460,nop,wscale 
7,sackOK,eol], length 0

I use pcengine APU system, the model is AMD G-T40E Processor with 3 NIC ( I 
believe It could be something related to a NIC setting somewhere but really 
don’t know)

Is someone encounter the same issue than me ? maybe it’s just a setting in the 
NIC driver ? 

Anyway thank you so much in advance if you have an idea because I passed a lot 
of hours/days on this problem and I really can not find a solution :(

Best regards,


Jean-Laurent Ivars 
Responsable Technique | Technical Manager
22, rue Robert - 13007 Marseille 
Tel: 09 84 56 64 30 - Mobile: 06.52.60.86.47 
Linkedin    |  Viadeo 
   |  www.ipgenius.fr 

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Setup DNS question

[Chris Buechler]

On Fri, Jun 24, 2016 at 5:35 PM, Richard A. Relph  wrote:
> Brand new pfSense user here… setting up a VMWare system after upgrading it to 
> 2.3.1_5, doing a reset to factory config, and restarting the web configurator.
> I get to this point:
>
>
> and what I want to say is have this pfSense instance have all LAN DNS queries 
> go to the DNS servers configured here. Ignore the DNS servers requested by 
> LAN clients, and ignore DNS servers specified from the WAN DHCP server.
>
> So I filled in the 2 boxes with the DNS server IP addresses, unchecked the 
> Override DNS box, and then went to Services > DNS Resolver and enabled DNS 
> Query Forwarding as described.
>
> No dice… no DNS queries succeed. Uncheck the DNS Query Forwarding box and DNS 
> works fine.
>
> What am I misunderstanding?

Your DNS servers probably don't support DNSSEC. Disable DNSSEC and
it'll probably work.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] CPU Utilization on landing page

[Chris Buechler]

On Fri, Jun 24, 2016 at 12:46 PM, Karl Fife  wrote:
> Scaling down the update frequency on the traffic graphs seems to
> meaningfully reduce utilization.  Many other widgets don't appear to have
> have settings for their poll intervals.   Are there other settings hidden
> away reduce the update frequency (to prolong the suitability of older
> hardware)?
>

Most don't. Might be worthwhile to add (pull requests welcome).

> I know that old routers have to meet their makers eventually, but I hate to
> do so only because dashboard starts causing real-time applications to fall
> over.
>

It took you 5 instances of the dashboard to reach 70% CPU, how many
duplicate dashboards do you want to run? :) Running one or two
instances of the dashboard on your system won't have any noticeable
impact unless you're already running way too close to the top end
capacity of the hardware.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] PCI/PCIe crypto cards?

[Chris Buechler]

On Fri, Jun 24, 2016 at 6:15 PM, Cheyenne Deal  wrote:
> Is there a list of working crypto cards for x86 and 64bit PC versions of
> pfsense 2.3 release line?

https://www.freebsd.org/releases/10.3R/hardware.html#crypto-accel

Though AES-NI is your best bet at this point.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Traffic Limiter name change

[Chris Buechler]

On Fri, Jun 24, 2016 at 1:01 PM, Karl Fife  wrote:
> We've entered the wonderful world of the traffic limiters. Specifically, we
> put FACEBOOK subnets through a comparatively skinny pipe.  This is done to
> make it JUST a bit too painful to look at kitten photos, but perfectly
> suitable to look at CompetitorCo's facebook page for legitimate business
> purposes. We're still collecting empirical data on how much it disuades
> personal use, but it doesn't seem to create tension the way that explicit
> blocking would.
>
> The issue:
>
> in <=2.2 if an in-use limiter is renamed, the system will yell at you.  IMO,
> that's good.
>

That's not true actually. No input_errors there when renaming a
limiter. You can't delete one that's in use. 2.3 is the same in that
regard.

There is a bug ticket open on updating firewall rules when a limiter
is renamed (or preventing renaming) to avoid removal of limiters from
rules when renamed. That's no diff than it's ever been though.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold