I allow to set up the "defalut" routes by OpenVPN and polls a.e. 8.8.8.8 to check, if the tunnel is up.
So, I don't need the gateway IP to monitor.

Thomas

OP, first, you don't need to black out reserved addresses, they're not routed anyway.

I'm glad you got it working, but if you have access to the server end, adding a route your LAN subnet would've solved your issue also.

With your current setup, while it works, the server end loses the ability to isolate connections coming from your network.  If that's not a concern from either side, then I guess you're good.

OP, can you share with us why you went with a bridged solution to begin with?

Thank you. I just didn't quite understand it, and that's exactly what I was looking for.

Very much appreciated.

Hi jimp, these steps aren't working for me. I have a very tiny change to the above problem in that I have an SG-2220, so only 1 LAN port. I made a new interface for a VLAN and set that vlan as the mirror interface for the VPN, but I'm not seeing any traffic.

Do you think maybe something is simply dropping the VLAN packets because they have no destination? Or are there any extra steps to span to a vlan?

EDIT:

Some people might want to see https://forum.pfsense.org/index.php?topic=49930.0 - this solved my issue with VPN suddenly not working anymore after assigning the interface. Another day saver by jimp!

I think maybe there is an issue with the bridging. When I run

tcpdump -nAi ovpns1 host 192.168.40.60

I see all my phone's traffic. When I run

tcpdump -nAi igb1_vlan8 host 192.168.40.60

I see nothing. Would this indicate I totally broke something? I have:
VPN -> ovpns1 (VPN Name) as an enabled interface,
VPNSPAN -> VLAN8 on igb1 (VPN Span) as an enabled interface, and
BRIDGE0 (Members: VPN)

Yeah you usually have to do some work to NAT OpenVPN clients.  Especially if they're not going out a WAN port.

You want to look in Firewall > NAT, Outbound tab for any entries with LAN as the interface.

The Log on client is just saying, restarting process.
The Log on the firewall says CMD Status and Client disconnected..

Had it setup this way before and didn't change anything to the port 443 so don't know what else should now use it after upgrade?!
Also already tried another port 4433, isn't working either.

I didn't do anything just upgrading to 2.2.4 and after reboot no more connections were possible.

best regards.

Thank you very much, for your answers. I have to open a new post though, as my windwos firewall is turned off (details in new post), VPN connection seems stable, allow all rule is set under OpenVPN, but i cannot ping or otherwise reach a client in my target network.

Best regards, Mister IX.

Could someone please provide any information as to what they think I am missing?  I do think it's a very simple mistake and I am missing something trivial.

Hi jimp,

You where right.

I issued the client certificate while it had to be the server certificate.

It is working now.

Many thanks,

Sebastiaan.

If a connection is stuck at UNDEF that means that it's stuck before it identifies itself, either it has not or cannot send its certificate or credentials. The logs on both sides may be of more help, but generally when this is seen it's because there is poor connectivity between the client and server.

Upgrading is important, though it may not help you with this particular case.

I have a 50Mbps/10Mbps Comcast business account and I use Private Internet Access (CA) and I can hit those speeds without issue.  I use BFC-128 encryption, otherwise I have the same settings posed by someuser123. I had compression enabled but that would cause FPS/MOBA games to lag when there were simultaneous downloads running like steam updates.  I turned compression off and the lag went away.  CPU usage didn't change much.  General internet usage never suffered from the lag.

My Firewall has no hardware AES support.  It's a converted HP Thin client running an AMD Turion X2 TM-84

Well if you can not resolve something with using the resolver than you have other issues..  Nobody would work using your resolver on your network, not just vpn users.

I take it you really don't understand what the difference between forwarding and resolver is?

If you want clients to resolve local stuff then they should have 1 dns - the dns that has your local stuff in it.  This dns then should either resolve for forward.. When you place multiple dns in a client where some are public and some are local you have no real idea when the client would use 1 vs the other, and depending on what is returned either refused, serv fail or nx can determine if the client asks the other dns in its list.  Or if just times out talking to one of them.

This is not a good strategy to count on client asking the correct dns for what its looking for by switching back and forth between them.  For one in this scenario you end up asking say google for your local stuff.  Which is just waste of time and could be seen as information leak.

Without seeing a diagram of how this is all wired together, my first guess would be that there's an improper setup of an  internal firewall or configuration setting in the devices that don't work.

When an external client connects via OpenVPN, it will appear to an internal device that it has an IP address outside the internal LAN.
Some devices either fail to recognize or actively block those types of addresses.

The other possibility is you've got something(s) wired wrong.
Without a diagram, it's pretty hard to say.

so why would you not have put this in the original thread..  And in that thread you were talking about web access and port forwarding not from remove vpn client.. But yes your router to your "source" now removes your asymmetric routing problem.

This is the original thread you are talking about is it not?
https://forum.pfsense.org/index.php?topic=97861.0

Good news. More forum searching with a few different terms and I came across this post. https://forum.pfsense.org/index.php?topic=76735.15

This lead me to upgrading the older pfsense install I had at the remote location. After upgrading the tunnel came up and I tested more backups with my original way of using rsync.

So far so good, I have transferred many gigabytes over this tunnel without any random crashes.