Sorted out.

As imagined, the problem was routes. I had realized that was intermittent. An hour traffic going through a VPN, another hour went by another.

The solution was to mark the option that our friend posted verdi. "don't pull routes".

I did it in the second VPN and normalized access instantly.

Now the internet will for my WAN and the access of the VPNs will by their respective interface through NAT.

It's been a while since I've actually run an OpenVPN server or client but roughly speaking:

Assign the tun(4) interface used by the OpenVPN client as an OPT interface at the Interfaces->(assign) menu.

Create a new outbound NAT rule at Firewall->NAT, set interface in the rule to the newly created OPT interface, leave everything else at defaults.

I've done some additional diagnostics and found that after much trial and error, firewall B is seeing traffic (I shut off all rules, address an easy pass rule and logged it) and then verified it with a packet capture however, even with Windows firewall turned off (and the port open), I'm not seeing a response from the server like it's still not getting to it….

@cmb:

Import your CA certs as a chain into a single CA config entry.

Actually I did that. But it does not solve the problem completely. Still CSRs generated locally and signed by the intermediate CA are showing with issuer external. However, if I generate the CSR, sign them with the intermediate CA and upload the certs BEFORE installing the Intermediate CA (ca-chain) then they are recognized as being issued by the intermediate CA once the intermediate CA is added.

That's the basic idea, although I wouldn't suggest the hardware I'm running is particularly high powered (or even new for that matter, 7+ years old).

I have learned that more memory is an asset as well - again within limits.
512MB is tight in some scenarios (I still have one box with 384MB! ), 1GB is good, 2GB is great, 3GB+ is fantabulous.

The packages caveats always apply, asking the box to do more than route and basic firewall and/or VPN adds to the required resources.

When you get to the Snort/Suricata, Clamv, setups a whole different set of parameters get invoked that are best described in their respective forums.

@viragomann:

@Damned:

@viragomann:

On which interface is this taken? At pfSense2 take a packet capture on WAN interface.

pfSense 1 is the upstream gateway on pfSense 2 or is there another way to the internet?

This is from pfsense2 (192.168.30.105) on WAN interface with filter for host address: 192.168.50.100

I think pfsense is upstream gateway of pfsense2 yes. I'm not familiar with the term

So you should also see this if you take a packet capture at pfSense 1 on DMZ and OpenVPN, right?

Yes I should. The capture is from the WAN-side of pfSense2

It has interfaces:

WAN manual 192.168.30.105 LAN manual 192.168.40.1 OPT1 manual 192.168.50.1

And pfsense1 looks like:

WAN 1000baseT <full-duplex>192.168.1.2 LAN 100baseTX <full-duplex>192.168.20.1 OPT1 1000baseT <full-duplex,flowcontrol,rxpause,txpause>192.168.30.1</full-duplex,flowcontrol,rxpause,txpause></full-duplex></full-duplex>

EDIT:
Packet capture looks exactly the same when running on pfSense#1 (192.168.30.1) for OpenVPN interface

EDIT#2:

I'm starting to believe it is either a pfSense2 issue, or a XenServer issue.

In XenServer I've simply created 2 VLANs, 1 and 2.

My previous statement that the VMs under pfsense2 have internet access only seems to be half truth.
Pinging works fine. I get decent latency I think ~10ms to hosts in my country, ~150ms for pfsense.org with no package loss.

Tried accessing a host over ssh. I can see in the host's auth.log that I'm trying to connect. Then my ssh-client on my PC just disconnects. Something about a socket, afraid I can't remember the exact message

However when I tried a wget, it got stuck on waiting for HTTP response. I had to cancel it.
Tried a netinstall of debian - it took forever. Eventually it said it could not reach the mirror.

Went ahead and did a netinstall on the same network as the XenServer host (pfSense1) - no issues at all. wget works fine, getting 27MB/s.

Guess I'll have to search around for XenServer VLAN performance a bit…

EDIT#3:
Well this looks like it!
https://forum.pfsense.org/index.php?topic=85797.0

I'll give it a try next time i can.

@kesawi:

##Send specific source hosts via VPN acl src_to_vpn src 192.168.1.20/30 192.168.1.24/31 tcp_outgoing_address XXX.XXX.XXX.XXX src_to_vpn

Is this different from the following option in Squid>General

This above GUI option does not specify the gateway to be used, whereas the code you mentioned does. Any idea where to put your options in Squid 2.3 GUI?

Strange thing, it worked with the movement of tls key, but still same kind of problem.

But if I insert a space (or any char) somewhere in the key windod and deletes it, ans same thing in advanced window (which looks like:

persist-key; persist-tun; remote-cert-tls server; key-direction 1; reneg-sec 432000

and save, then I can connect. otherwise I get auth failed after disconnection.

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

Here's instructions on how to set up OpenConnect as a server:

https://wiki.openwrt.org/doc/howto/openconnect-setup

Hi,

Connecting with latest client 2.3.10 to server on a NAS running version 2.3.6, it`s working, my server log:

Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

My client log:

Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

I use

tls-version-min 1.2 or-highest cipher AES-256-CBC auth SHA512

in server and client config.

I dont know if this can be set in PFS because Im waiting for a case for my first PFS build but OpenVPN seems not to be the limit?

I'm getting the same error, I'm not sure why either.  :-\

Updated to Version 2.3-RELEASE
Still the same error trying to connect to the openvpn-Server…

If i install a debian on the same hardware, the vpn will nearly max out my connection. on freebsd it's still very slow.
Seems like i still can't use it.

Any more help?

using 2.3.9

[2.3-RELEASE][root@pfSense.local.lan]/root: openvpn –version
OpenVPN 2.3.9 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Mar 31 2016
library versions: OpenSSL 1.0.1s-freebsd  1 Mar 2016, LZO 2.09
Originally developed by James Yonan

That would be entirely up to your client. OpenVPN itself only routes by IP address or subnet. There is no concept of routing by port at the IP level. I don't think any clients support doing what you propose currently, however.

If it was a site-to-site firewall and there was a pfSense firewall in front, then you could do some work to policy route port 22 into an OpenVPN connection, but that is a bit different situation.