pfSense Gold Subscription

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 - JKnott

Pages: [1] 2 3 4 5 ... 66
1
Quote
If I send a 64KiB ICMP packet, I expect it to be fragmented as it leaves the source because no switch I know supports 64KiB jumbo frames.

The original datagram, which can be as large as 65K can be fragmented to fit the MTU.  Packets at this point are not fragmented.  If they have to travel over a link with a smaller MTU, then a router will fragment the packets.  At this point there will be a fragment offset etc., to show the packet has been fragmented somewhere along the path, but not at the source.

Fragmented datagrams, entirely normal.
Fragmented packets, occur only when a packet passes through a link with a smaller MTU.

However, fragmenting packets does not happen with IPv6, but fragmenting datagrams still does.  Path MTU discovery is mandatory with IPv6, to ensure packet fragmentation is not needed.  There is also a trend to this with IPv4 & PMTUD.

2
I can disable IPv6.

The only setting I can see is where the MTU has been entered with value 1500.

I can try to enter that, and will post another log file

Normally PPPoE uses 1492.  This is to allow the PPPoE header to fit within the Ethernet frame, along with user IP packets.  Going smaller than necessary won't cause problems but larger might.


3
NAT / Re: Wan and Lan on same IP range for test lab
« on: Today at 09:38:37 am »
Would it be something I could do, if I could setup an additional range of ip addresses on my normal network to be something like 172.16.240.x  as well as 172.16.0.x and then have the 172.16.240.x address assigned as the outside gateway of the virtual pfsense, then use the 172.16.0.1 as the inside interface of the pfsense?

You cannot have 176.16.240.x on both interfaces.  They must be different.  You could have 172.16.240.x on the WAN and 172.16.0.x on the LAN.

Once again, you cannot have the same address range on both sides of a router.

4
Quote
it only had 4 strands of copper....

Which 4 strands?  10 & 100 Mb only require 2 pairs, on pins 1, 2, 3 & 6.  Of course, they have to be proper twisted pairs, not the no pair silver satin stuff.

5
^^^^
I see that too.

However, sending all traffic through the tunnel is recommended for "road warriors" who use public WiFi.  Your traffic can't be snooped then.

6
Quote
pablo@damnb00k:~/Downloads$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.99.1    0.0.0.0         UG    50     0        0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlan0
192.168.0.0     192.168.99.1    255.255.255.0   UG    50     0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

Current OpenVPN versions will not do that. You will get two /1 routes instead:

0.0.0.0/1
128.0.0.0/1

Look elsewhere for the source of that route.

Where do you see those two?  The two 0.0.0.0 routes are normal, the first is for the tunnel and the second for the actual interface.  The 0.0.0.0 genmask indicates that all addresses are included.  The tunnel has a lower metric, so it will be used as the default route.  Even in routers from Cisco, Adtran, etc., the routing is done through 0.0.0.0.  The /1 means a subnet mask with only the most significant bit being used to identify a network.

Here's what I get here:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.255.1    0.0.0.0         UG    50     0        0 tun0
0.0.0.0         172.16.4.1      0.0.0.0         UG    100    0        0 eth0
172.16.4.0      0.0.0.0         255.255.255.0   U     100    0        0 eth0
172.16.255.0    0.0.0.0         255.255.255.0   U     50     0        0 tun0
174.115.32.127  172.16.4.1      255.255.255.255 UGH   100    0        0 eth0

7
No, it's not packets under a certain size, it fragments.  Like other packets, fragments can be any legal size, but they are only part of the original packet and have the fragment offset etc..  Fragmented packets are caused by routers connected to links with a smaller MTU than the original network.  I also don't understand how a source would fragment a packet when it's supposed to fragment the datagram to fit the MTU.  What would happen with this on IPv6, where packet fragmentation isn't allowed?

8
I noticed the same with IPv6.

9
OpenVPN / Re: Site to site between 4 offices
« on: Yesterday at 01:10:41 pm »
Do you have rules to allow access to the VLANs?  I have attached an example.

10
Firewalling / Re: Weird Problem
« on: Yesterday at 12:41:27 pm »
That sounds like an ISP/carrier issue.  If you can reach every (did you really reach every single one?   ;)) web site in your country, it's clear pfSense is doing it's job and sending traffic out to the Internet.

11
Something is clearly wrong here.  If it was fragmented at source, you shouldn't be seeing fragments at all, just a series of un-fragmented packets containing the fragments of the original datagram.  If you're seeing fragmented packets, as shown in that capture, they're being fragmented elsewhere.  Was that capture actually at the source?  Or the destination?

12
Well, if the packet is fragmented along the path, what do you expect to be able to do about it?  You can't recreate the packet, when part of it is missing.  I haven't used StrongSWAN, so I can't comment on it, but generally the solution to this sort of problem is to limit the tunnel packet size.

The question still remains, why are oversize packets being sent?  Those appear to be close to 2400 bytes original size, which should never happen if the MTU is set to 1500.  If the datagram was properly fragmented before transmission, you wouldn't be seeing those fragments.

13
Hi @JKnott,

I think you misunderstand what I want to do. pfSence is fine, we have no problem with pfSense handling this traffic. But, for a LAB environment where we are indicating to students of potential real world issues, we want to replicate this issue with pfSense, in order that they can see the outcome that they might come across. We use pfSense in a multitude of ways like this, to induce problems in order that we can then diagnose the issue in class in a "real" (fake) environment. pfSense is awesome like this :).

In pretty much all of the cases I have seen that show this issue, there is always a firewall tweak that can be made.

The IKE AUTH packet (StrongSwan) is just big. Yes it is fragmented at source, but not all infrastructure has been set to handle these fragments.

So, I'm looking to create this problem, no actually solve it :)

I guess I misunderstood this:
Quote
One problem we come across in the real world is that large UDP datagrams that have been fragmented, but then the fragment is dropped on route to the final destination, thus making the datagram useless as only the partial packet turns up. This particularity affect IPsec setup where the IKE AUTH datagrams are >1500 bytes.

If it's a real world problem the question remains why aren't those fragments making it through the 'net.  Also, fragmenting at source is different from fragmenting in routers along the path.  The fragment offset I mention would only be in packets that have been fragmented by routers.  The source will simply break up the original datagram into bite size pieces that fit the MTU.  The original datagram can be as big as 65K and spit up into individual non-fragmented packets.


14
Your situation raises 2 questions:
1) Why are the fragments being lost?  Each fragment should be able to be passed along the entire path.
2) Why is IPSec sending packets that large?  Are they being fragmented at source, as they should be?  Also, why isn't path MTU detection working.  Take a look at the IPSec packets to see if the do not fragment flag is set.  PMTUD requires it.

15
General Questions / Re: How to make use of VLANs
« on: Yesterday at 10:36:53 am »
Quote
The issue is not with the switch (which is a Netgear GS108E) which working fine, it seems to be an issue with the TL-Link AP and it's poor understanding of VLANS.

While your issue may be about the AP, the overall point is that TP-Link should be avoided when VLANs are going to be used.  As I mentioned, they don't seem to understand them.  Regardless, when you get an AP that properly supports VLANs, you will still have to configure the switch with trunk ports for both pfSense and the AP.

Pages: [1] 2 3 4 5 ... 66