Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - muppet

Pages: [1] 2
1
NAT / Re: voip nat over pfsense with open vpn
« on: February 14, 2018, 04:13:06 pm »
Why don't you TCP dump on each pfsense and see what you're seeing?

If you can ping the xivo server, but softphones can't connect, I'd wonder if you need a Firewall rule to allow this traffic, or if the Xivo server isn't configured to listen for VoIP/SIP connections from anything other than 192.168.2.0/24 (i.e you need to add a permit access from 192.168.1/24 rule somewhere, either on the pfSense or maybe the xivo server config)

2
NAT / Re: Intermittent NAT failures
« on: February 13, 2018, 05:17:49 pm »
Kept a tcpdump going for ~8 hours yesterday, never saw any non-natted packets egressing my pppoe interface.

Realise this doesn't really help you, just another data point.

3
General Questions / Re: Ping spikes on new install
« on: February 13, 2018, 05:16:16 pm »
Maybe try disabling MSX-I and/or Flow Control?

https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards

Also try running using a RAM disk (System->Advanced->Misc), maybe your pfSense writing logs to disk causes the system to pause/freeze up for a moment?

These are all just stab-in-dark guesses now :(

4
NAT / Re: Intermittent NAT failures
« on: February 12, 2018, 02:37:11 pm »
I haven't seen anything similar, but I'll keep a tcpdump running on my PPPoE interface towards the world and see if it picks up any un-natted packets (2.4.2p1)

5
General Questions / Re: See pppoe uptime from CLI?
« on: February 12, 2018, 02:27:09 pm »
It looks in the PPP log and finds the connect time and then calculates.

https://github.com/pfsense/pfsense/blob/master/src/etc/inc/pfsense-utils.inc#L1472
That's a clever way to do it!
Thanks for the pointer.

6
Cause Found!

If Disable Firewall Scrub is ticked (i.e. the Firewall strub is disabled) then the packets are dropped.

If the option is unticked (The default) the packets pass.

Still curious as to why this is - I've noticed it only happens towards Google (8.8.8.8 and 8.8.4.4)

Towards other hosts it didn't matter if this option was ticked or not.

I'd love to fully understand why, does anyone with knowledge of the pf/scrub option have any thoughts?

7
Probably bad form to reply to myself?

Anyway, I can reproduce this from the pfsense CLI itself:

ping 1444 = works
ping 1445-1464 = silent fail
ping 1465 = ICMP Must Fragment received

Code: [Select]
[2.4.2-RELEASE][admin@trogdor.muppetz.com]/var/log: ping -D -s 1444 -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1444 data bytes
1452 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=36.418 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 36.418/36.418/36.418/0.000 ms
[2.4.2-RELEASE][admin@trogdor.muppetz.com]/var/log: ping -D -s 1445 -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1445 data bytes

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
[2.4.2-RELEASE][admin@trogdor.muppetz.com]/var/log: ping -D -s 1464 -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1464 data bytes

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
[2.4.2-RELEASE][admin@trogdor.muppetz.com]/var/log: ping -D -s 1465 -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1465 data bytes
36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 05d5 0000   0 0000  40  01 2519 202.137.243.17  8.8.8.8


--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

So it doesn't appear the LAN interface even forms part of the problem.

8
Hi,

I'm seeing some odd behaviour with ICMP and I'm hoping someone can point me in the right direction.

My setup is as follows

ISP---[PPPoe]----WAN[pfSense]LAN---Client

My pfSense is virtualised, using VirtIO drivers, atop of KVM/Proxox.  I have turned off all checksumming.  Because of PPPoE, my MTU is 1492 for packets heading to the Internet. Traffic in general passes fine, though I have noticed some edge cases of TCP stalling/dropping which to me appears to be an MTU problem.  Thus I've gone looking and ended up here today.

From my client, a Linux PC, I see the following behaviour:
(note all pings being run with DO NOT FRAGMENT requested)

Ping with very large size and the expected reply:
Code: [Select]
tim@micro:~$ ping -M do -s 1490 8.8.8.8 -c1
PING 8.8.8.8 (8.8.8.8) 1490(1518) bytes of data.
ping: local error: Message too long, mtu=1500

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Ping with 1444 size - I get a reply as expected.
Code: [Select]
tim@micro:~$ ping -M do -s 1444 8.8.8.8 -c1
PING 8.8.8.8 (8.8.8.8) 1444(1472) bytes of data.
1452 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=36.4 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 36.456/36.456/36.456/0.000 ms

Ping with a size of 1465
Code: [Select]
tim@micro:~$ ping -M do -s 1465 8.8.8.8 -c1
PING 8.8.8.8 (8.8.8.8) 1465(1493) bytes of data.
ping: local error: Message too long, mtu=1492
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Ping with a size of 1464 (one less than previous ping)
Code: [Select]
tim@micro:~$ ping -M do -s 1464 8.8.8.8 -c1
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

The last one there is dropped.  No "must fragment" is received.

However when I tcpdump my pppoe0 interface when sending the ping -M do -s 1464 8.8.8.8 I do see both the pings leaving the box AND the replies being received:

Code: [Select]

tim@micro:~$ ping -M do -s 1464 8.8.8.8 -c 3
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.

--- 8.8.8.8 ping statistics ---

----------------------------- TCP DUMP ON PPPoE Inteface OF ABOVE 3 PINGS ---------------------------------

[2.4.2-RELEASE][admin@trogdor.muppetz.com]/root: tcpdump -i pppoe0 icmp and not host 202.56.33.251
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes
10:27:13.670050 IP 202-137-243-17.static.nownz.co.nz > google-public-dns-a.google.com: ICMP echo request, id 21470, seq 1, length 1472
10:27:13.706961 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: ICMP echo reply, id 21470, seq 1, length 1448
10:27:13.707021 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: icmp
10:27:14.697492 IP 202-137-243-17.static.nownz.co.nz > google-public-dns-a.google.com: ICMP echo request, id 21470, seq 2, length 1472
10:27:14.731000 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: ICMP echo reply, id 21470, seq 2, length 1448
10:27:14.731098 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: icmp
10:27:15.737654 IP 202-137-243-17.static.nownz.co.nz > google-public-dns-a.google.com: ICMP echo request, id 21470, seq 3, length 1472
10:27:15.771040 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: ICMP echo reply, id 21470, seq 3, length 1448
10:27:15.771090 IP google-public-dns-a.google.com > 202-137-243-17.static.nownz.co.nz: icmp


Doing the same command and doing a tcpdump on the LAN interface, I see only 1-way traffic:

Code: [Select]

tim@micro:~$ ping -M do -s 1464 8.8.8.8 -c 3
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2059ms

----------------------------- TCP DUMP ON LAN Interface OF ABOVE 3 PINGS ---------------------------------

[2.4.2-RELEASE][admin@trogdor.muppetz.com]/root: tcpdump -i vtnet1 icmp and not host 202.56.33.251
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet1, link-type EN10MB (Ethernet), capture size 262144 bytes
10:28:55.129186 IP micro.muppetz.com > google-public-dns-a.google.com: ICMP echo request, id 1873, seq 1, length 1472
10:28:56.148912 IP micro.muppetz.com > google-public-dns-a.google.com: ICMP echo request, id 1873, seq 2, length 1472
10:28:57.189876 IP micro.muppetz.com > google-public-dns-a.google.com: ICMP echo request, id 1873, seq 3, length 1472


If I look at the session table for 3 failing pings I see:
Code: [Select]
LAN icmp 192.168.0.5:1874 -> 8.8.8.8:1874 0:0 3 / 0 4 KiB / 0 B
WAN icmp 202.137.243.17:32606 (192.168.0.5:1874) -> 8.8.8.8:32606 0:0 3 / 0 4 KiB / 0 B

If I look at the session table for 3 passing pings I see:

Code: [Select]
LAN icmp 192.168.0.5:1880 -> 8.8.8.8:1880 0:0 3 / 3 4 KiB / 4 KiB
WAN icmp 202.137.243.17:48100 (192.168.0.5:1880) -> 8.8.8.8:48100 0:0 3 / 3 4 KiB / 4 KiB

To recap:

ping -M do -s 1444 is the maximum I can send and get replies from my Linux PC.
ping -M do -s 1445 through -s 1464 are dropped silently somewhere in pfSense, even though I see them incoming on the PPPoE interface with TCPDump, I don't see them egress the LAN interface and the Linux PC never gets a reply.
ping -M d0 -s 1465 gives me ping: local error: Message too long, mtu=1492 as expected.

Aaahhhh I've just found they're being dropped by the Firewall!

But why?

Code: [Select]
Feb 12 10:45:03 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,1042,0,+,1,icmp,1468,8.8.8.8,202.137.243.17,reply,33195,11448
Feb 12 10:45:03 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,1042,1448,none,1,icmp,44,8.8.8.8,202.137.243.17,
Feb 12 10:45:04 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,1590,0,+,1,icmp,1468,8.8.8.8,202.137.243.17,reply,33195,21448
Feb 12 10:45:04 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,1590,1448,none,1,icmp,44,8.8.8.8,202.137.243.17,
Feb 12 10:45:05 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,2061,0,+,1,icmp,1468,8.8.8.8,202.137.243.17,reply,33195,31448
Feb 12 10:45:05 trogdor filterlog: 9,,,1000000103,pppoe0,match,block,in,4,0x0,,56,2061,1448,none,1,icmp,44,8.8.8.8,202.137.243.17,

What rule is causing them to be discarded?

9
General Questions / Re: SSH tunnel with putty very slow
« on: February 08, 2018, 12:18:24 pm »
I've just tested this myself and I get great performance via a SSH port forward/tunnel.

I'm using PuTTY to do my port forwarding under windows, you don't say what you're using. EDIT: Sorry, you say right there in the subject.

Regardless, I don't think the problem is pfSense.  I have a similar machine, i5 5250U but my pfSense is virtualised on it, so it should be even slower theoretically.

I would examine the following:
  • Client you're using (PuTTY etc)
  • TCPDump/Wireshark the connection and see if you're getting a lot of out of order TCP, or MTU problems

It might also be that the restrictive firewall is limiting SSH traffic.

Hope this helps (Though I realise how annoying "works for me!" posts are)

10
Traffic Shaping / Re: Monitoring Not Showing Queue Traffic?
« on: February 07, 2018, 04:07:33 pm »
Yes, both of those show the correct information.
I just wondered why the monitoring wasn't working correctly - it's interesting (but only that, interesting, it doesn't matter) to go back and look how the pfSense box handled heavy load and what traffic went where.

I wonder if I should submit a bug report?

Thanks!

11
OpenVPN / Re: OpenVPN dpinger behavior question
« on: February 06, 2018, 07:49:55 pm »
I see the same on my pfSense 2.4.2_1:

Something triggers when check_reload_status is run that causes dpinger issues.

Not a biggy, but I too have noticed this.

Code: [Select]
Feb 6 20:48:20 rc.gateway_alarm 72290 >>> Gateway alarm: WAN_PPPOE (Addr:X.X.X.X Alarm:0 RTT:3906ms RTTsd:1128ms Loss:0%)
Feb 6 20:48:20 check_reload_status updating dyndns WAN_PPPOE
Feb 6 20:48:20 check_reload_status Restarting ipsec tunnels
Feb 6 20:48:20 check_reload_status Restarting OpenVPN tunnels/interfaces
Feb 6 20:48:20 check_reload_status Reloading filter
Feb 6 20:48:21 php-fpm /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_PPPOE.
Feb 6 21:46:58 php-fpm /index.php: Successful login for user 'admin' from: 192.168.0.106
Feb 7 01:46:58 rc.gateway_alarm 95168 >>> Gateway alarm: WAN_PPPOE (Addr:X.X.X.X Alarm:1 RTT:134683ms RTTsd:486359ms Loss:0%)
Feb 7 01:46:58 check_reload_status updating dyndns WAN_PPPOE
Feb 7 01:46:58 check_reload_status Restarting ipsec tunnels
Feb 7 01:46:58 check_reload_status Restarting OpenVPN tunnels/interfaces
Feb 7 01:46:58 check_reload_status Reloading filter
Feb 7 01:46:59 php-fpm /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_PPPOE.
Feb 7 01:47:12 rc.gateway_alarm 97132 >>> Gateway alarm: WAN_PPPOE (Addr:X.X.X.X Alarm:1 RTT:219457ms RTTsd:556905ms Loss:11%)
Feb 7 01:47:12 check_reload_status updating dyndns WAN_PPPOE
Feb 7 01:47:12 check_reload_status Restarting ipsec tunnels
Feb 7 01:47:12 check_reload_status Restarting OpenVPN tunnels/interfaces
Feb 7 01:47:12 check_reload_status Reloading filter

12
General Questions / Re: PPPoE issues since 2.4
« on: February 06, 2018, 06:25:15 pm »
I would run a tcpdump (Diagnostics->Packet Capture) on the WAN interface of the pfSense while this fault is happening.

Posting that to a pastebin where we can look at it would be helpful (you'll have to scrub any passwords etc, be careful here before just blindly pasting)

13
Traffic Shaping / Monitoring Not Showing Queue Traffic?
« on: February 06, 2018, 01:58:58 pm »
Hi,

I've got some queues setup for my traffic.  That's all working fine, traffic goes in the right queues etc, I'm really pleased with how well it works.

This is what pftop -v queue shows me:

Code: [Select]
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000                                                                                         08:53:25

QUEUE                             BW SCH  PRIO     PKTS    BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN     P/S     B/S
Bulk                                 priq    0        0        0        0        0    0                     0       0
Low                                  priq        219206 25099892        0        0    0                     3     460
Medium                               priq    2   890428  102133K        0        0    0                     0       0
High                                 priq    3     2169   321266        0        0    0                   0.2       8
VeryHigh                             priq    5    12646   988551        0        0    0                     0       0
Priority                             priq    7     1269   311483        0        0    0                     0       0

However this is what the monitoring page is showing me:



There's no traffic at all, as far as it's concerned.  I have do "Use RAM Disk" ticked - could this be the problem?
Other things like traffic stats etc show as I expect.

Thanks.

14
Hardware / Re: PfSense w/Squid: SSD still ill-advised?
« on: February 04, 2018, 02:15:34 pm »
Well it'll always be true (at least for the forseeable future) that an SSD "wears out" where as a spinning platter doesn't (though it can of course fail in many other ways!)

So I'd say that yes, the advice still stands, but for a small network you'll probably be OK.  Do you have plans/the ability to recover should the SSD fail hard in 5 years?  If yes, then I'd proceed.

I think the bigger question is, in 2018, what benefit does Squid give you on a small home network?  You can probably rest easier at night removing squid from the network.

If you're using squid just to do some sort of site ACL stuff, well if you have enough memory you can run squid "in memory" with no disk caching and thusly solve your "problem" that way too.

15
General Questions / Re: Ping spikes on new install
« on: February 04, 2018, 01:57:53 pm »
So even ping between two laptops, via pfSense, shows the problem?

Can you post the output of dmesg? I'm not a FreeBSD guru, but maybe we can spot something in there that might be the cause of the problems.

Pages: [1] 2