Messages

1

German - Deutsch / Re: ipsec site to site DSLite

« on: May 12, 2020, 08:28:40 pm »

Nun - wegen der Stabilität mache ich mir weniger Sorgen... Kritisch wird's halt wenn Dir das Ding jemand auf macht.

Hab mein IPSec inzwischen auch stabil am laufen. Nach diversen Experimenten mit MTU bin ich letztendlich dabei gelandet, MSS über die Firewall-Normalization zu setzen. Damit sieht erst mal alles gut aus.

Einziger Haken ist momentan, dass der Roadwarrior noch langsam ist und manuell die MTU/MSS anpassen muss.

Wenn WireGuard mal stabil ist, ist das definitiv auch etwas, was ich mir anschauen werde.

2

German - Deutsch / Re: ipsec site to site DSLite

« on: May 12, 2020, 06:10:05 pm »

Naja... klingt gut. Wenn da nicht der Haken wäre:

    The WireGuard VPN software is still in experimental state, use with caution.

Willst Du Dir das wirklich antun? Selbst für rein private Zwecke?

3

German - Deutsch / Re: ipsec site to site DSLite

« on: May 12, 2020, 02:53:11 pm »

Ich kämpfe gerade mit einem ähnlichen Setup:

- Büro: 1000MBit/s down, 50MBit up - öffentliche IP
- Home: 200MBit/s down, 50MBit up

IPSec-Performance extrem schwankend. An der Hardware liegt es nicht. Wenn ich beide Firewalls über einen Switch verbinde bekomme ich 200MBit/s mit AES256 durch.

Das Problem bei mir ist die MTU.

Büro -> Home: 2MBit/s
Home -> Büro: 20MBit/s

Wenn ich die Hart auf 1422 setzte bekomme ich in beide Richtungen 50MBit/s Durchsatz - so wie vom Provider versprochen. Allerdings habe ich dann massive Probleme mit iPads und anderen Geräten, die auch im Netz hängen und auf diversen Internet-Seiten nicht mehr funktionieren.

Ein weiterer Schlüssel bei der ganzen Sache scheint zu sein, das NAT-Traversal auf "Force" zu stellen.

Was mit auch noch nicht so ganz klar ist, ist wie das ganze mit den "Interface Scrubbing" der Firewall zusammen hängt.
Das sorgt wohl dafür, dass die "Do not Fragment"-Flags der IP-Pakete gelöscht werden und so Pakete automatisch fragmentieren... Aktuell vermute ich, dass das eher auf "Disabled" stehen sollte - sonst bekommen die Clients nicht mit, wenn sie zu große Pakete verschicken.

4

General Discussion / IPsec is creating and deleting connections every 5 seconds in a loop

« on: May 12, 2020, 11:21:16 am »

My IPSec log is currently flooded with messages that create/disable connections every 5 seconds but I have no idea where this comes from. Can anybody help?

The connection seems to be stable - I can access computers on the other side of the tunnel. Data transfer is stable but a bit slow.

...
2020-05-12T11:15:19   charon: 14[CFG] received stroke: route 'con2'
2020-05-12T11:15:19   charon: 06[CFG] added configuration 'con2'
2020-05-12T11:15:19   charon: 06[CFG] loaded RSA public key for "workwall" from '/usr/local/etc/ipsec.d/public/publickey-peer-2.pem'
2020-05-12T11:15:19   charon: 06[CFG] loaded RSA public key for "homewall" from '/usr/local/etc/ipsec.d/public/publickey-local-2.pem'
2020-05-12T11:15:19   charon: 06[CFG] received stroke: add connection 'con2'

2020-05-12T11:15:19   charon: 14[CFG] deleted connection 'con2'
2020-05-12T11:15:19   charon: 14[CFG] received stroke: delete connection 'con2'
2020-05-12T11:15:19   charon: 14[CFG] received stroke: unroute 'con2'
2020-05-12T11:15:19   charon: 06[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
2020-05-12T11:15:19   charon: 06[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
2020-05-12T11:15:19   charon: 06[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
2020-05-12T11:15:19   charon: 06[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
2020-05-12T11:15:19   charon: 06[CFG] loaded ca certificate "C=XXXXX, ST=XXXXX, L=XXXXX, O=XXXXX, E=XXXXX, CN=XXXXX" from '/usr/local/etc/ipsec.d/cacerts/f1c0f879.0.crt'
2020-05-12T11:15:19   charon: 06[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
2020-05-12T11:15:19   charon: 06[CFG] expanding file expression '/usr/local/etc/ipsec.secrets.opnsense.d/*.secrets' failed
2020-05-12T11:15:19   charon: 06[CFG] loaded RSA private key from '/usr/local/etc/ipsec.d/private/privatekey-local-2.pem'
2020-05-12T11:15:18   charon: 06[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
2020-05-12T11:15:18   charon: 06[CFG] rereading secrets
2020-05-12T11:15:14   charon: 06[CFG] received stroke: route 'con2'
2020-05-12T11:15:14   charon: 10[CFG] added configuration 'con2'
2020-05-12T11:15:14   charon: 10[CFG] loaded RSA public key for "workwall" from '/usr/local/etc/ipsec.d/public/publickey-peer-2.pem'
2020-05-12T11:15:14   charon: 10[CFG] loaded RSA public key for "homewall" from '/usr/local/etc/ipsec.d/public/publickey-local-2.pem'
2020-05-12T11:15:14   charon: 10[CFG] received stroke: add connection 'con2'

2020-05-12T11:15:14   charon: 12[CFG] deleted connection 'con2'

...

5

General Discussion / VPN performance, MTU sizes and Firewall Scrubbing

« on: May 12, 2020, 10:28:15 am »

I have the following setup:

- 2 Firewall computers, both with good performance (I am getting 300Mbit AES256 when directly connected with a switch).
- Internet Office: 200MBit down, 50MBit up, directly connected to the internet
- Internet Home: 1000MBit down, 50MBit up, but behind provider NAT

So I can only create an IPSec tunnel from Home->Office using tunneling, not routing at the moment.
Connection is up and stable.

I have no special setup for ICMP handling.

I had a bad performance from Office->Home with 2MBit and 30MBit in the other direction.

I tried to test the MTU size using `ping` but that did not work. So I used `iperf` on both sides of the tunnel. Found out that I get full 50MBit in both directions when I use an MTU of 1422.

I also had to set `NAT Traversal: Force` on the office side.

My first idea was to get the LAN MTU to 1422 and everything should work... but did not.
So my next try was setting the MTU through DHCP. Works for Linux. Does not work on macOS (the Macs simply ignore MTU settings in DHCP). It also seems that several mobile devices (connected to the firewall now have issues accessing some webpages).
I had no issues here when the MTU size was 1500.

I've also learned that the problem with testing the MTU size comes from the fact that OpnSense by default does "Interface scrubbing" which kills the "Do not fragment" flag from the IP packages and allows fragmented packages instead to allow access to servers which set do not fragment.

What I'd like to understand is

1) Do I have to allow ICMP in the firewall? Or is OpnSense already accepting the "packet too big" messages by default?

2) Should I set Firewall / Normalization / Disable interface scrub? Or better: What should I set or not?

3) Would using a routed tunnel solve the issue? Can I set the MTU on the tunnel interface instead?

4) Other ideas?


---

Update:

I've disabled "Interface Scrubbing" and set MTUs back to default. It seems my mobile devices and computers connected over the wifi can finally access all internet pages again.