@mlohr said in Possible bug: Newline stripped on saving:

Yeah, this way it works. But why are some newlines stripped and some not?

It doesn't matter, because newlines are not supported in that box. Use semicolons to separate entries and you'll never have to worry about it again.

As to the why, it's probably a difference in browsers and UNIX/Windows newline styles, or who knows what. They're unreliable, hence the semicolon requirement.

You can for sure have unbound use VPN A for its queries - my point is trying to have it use vpn A for user B, and vpn C for user A or vlan X is just nuts!! For what possible reason is there to do such a thing..

Just have them all use vpn X.. If your trying to circumvent geo restrictions by using different vpns for different queries.. Your going have a shared cache.. So no going to work..

I agree that if you are connecting to other locations via vpn then the only way to make dns work the way you want it to is to have separate dns servers/caches for each.

Aliases do not work there. The local and remote networks are: Expressed as a comma-separated list of one or more CIDR ranges.

Tunnel network too, as you found out, but it's only one CIDR there.

@NogBadTheBad

Excellent! That did it, thank you.

So the issue was I had on the far side Block BOGON networks turned on for the LAN interface.

To use a wifi router as just an AP.. You don't need to do anything with their nonsense interface... Just turn off its dhcp server - connect it to your network via one of its LAN Ports!!! Set an IP on this lan port to work on your network.

Most of these nonsense native firmwares do not even allow you to put a gateway on the lan side interface.. So no you wouldn't be able to get to it remotely from another network.

Put some 3rd party on it like ddwrt or openwrt... If that doesn't work an it will not allow you to put a gateway on the lan interface - then source nat it on pfsense so that traffic going to the AP looks like it comes from the pfsense interface IP in that network.

@Gertjan said in OpenVPN and AES-NI?:

Or, that has been cancelled

Judging from those comments, I'd say postponed.

@Derelict Ah, that makes sense. Thank you very much for the help.

Some results with the 4690K. After a while of repeatedly switching servers, I started having problems running the test.

edit Results updated and sorted by number of servers (smallest to largest), then download speed (largest to smallest).

b5536258-f69f-4a59-99a5-faecde971092-image.png

So a option could be to use one machine for your regular stuff, working, steam, netflix, ... and another machine for anything you want to exit out the VPN by source IP, torrent and websites you browse with this machine.
This second machine could be either physical or virtual.

-Rico

Firewall (think windows firewall) on the client blocking the traffic?

Pretty much everyone who uses a Mac and wants OpenVPN to work buys a copy of Viscosity.

Probably a good time to run a 30-day trial.

Just sayin'.

@mare said in Connection reset when using OpenVPN:

(which is a primitive embedded device and can not use OpenVPN).

So... What does that have to do with natting and port forwarding?

If this 10.0.8.2 device is running openvpn.. You do not have to NAT you would route..

Check the OpenVPN Routing table in Status > OpenVPN
And give it a try with CSOs.

-Rico

For the record: I neglected to include this:

OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May 22 2019

2019-05-26 20:02:35.129809 library versions: OpenSSL 1.0.2r 26 Feb 2019, LZO 2.10

Tunnelblick: macOS 10.14.5; Tunnelblick 3.7.9 (build 5320)

That is just you killing the process when reconfiguring which terminates and restarts the client process. You are interrupting the system call that is listening for traffic when you give it the SIGTERM signal.

The more-telling log entries are the Inactivity-timeout entries. I'd be sure that 171.25.221.131 is actually receiving your traffic on UDP/1194, the TLS keys match, etc..

Checking OpenVPN staus, I get Bad compression stub (swap) decompression header byte: 42. My settings are right.