I'm sorry, I should've sent a picture from the beginning, I suck at explaining things. It looks like this: [image: 1570087848827-screenshot-from-2019-10-03-02-29-44-resized.png] Exact same rule as the above, except that it rejects and has no gateway selected. When the firewall is evaluating the traffic since the tunnel would be down and hence it doesn't match anymore, then the traffic would fall on the next rule, and, the next rules says sorry you can't pass. In the picture, it's a catch all rule, which is very dangerous because it can lock you out, so you need to add yet more rules for services in the firewall (or to other local networks): [image: 1570088423794-screenshot-from-2019-10-03-02-39-35-resized.png] Here, rules are: is automatically generated, it's disabled on the settings but I keep forgetting. :) is automatic as well, created by pfBlockerNG is my actual first rule, it bypasses the firewall completely. It catches all traffic from the alias def_fullchoya. allows traffic going to internal IP ranges (RFC1918: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16) since the interface address is 10.0.0.1, it therefore allows access to anything on the firewall and other local networks. Shouldn't be that broad though. allows internal DNS servers to get DNS outside of the tunnel (because it's above the tunnel rule) but in an ordered fashion, i.e; it's a gateway group that goes one by one checking what's [interface] up so DNS queries are region-matched. blocks all other DNS so clients are forced to get it from the servers specified though DHCP. allows certain hosts (alias def_fullthrottle) to use the local exit to the Internet at full speed but still use internal DNS (covered by rule 4) allows servers known to phone home, i.e; Microsoft products (alias bad_kiddies) to get internal DNS and communicate internally with other local hosts (covered by rule 4) but blocks them from actually communicating out. every other traffic goes through tunnel safeguard (negate) rule: if tunnel drops, traffic matches this rule rejecting traffic everywhere out. That would include local traffic if it wasn't covered by rule 4. The way you did it is good too but that I think that would create problems if you're hosting servers as it would block or create asymmetric routing from a remote client's perspective as most VPN services don't let you do port forwarding. In other less confusing words: when you add a rule on an interface, the firewall creates on the background a temporary pass rule for the return traffic on whatever the other interface for as long as the state lives even if there's a rule that blocks the traffic. In my case rule 8. In all honesty I'm not a hundred on if the floating rule would catch autogenerated rules passing traffic from blocking rule 8 but that's exactly what floating rules are for. They're for complex scenarios and should be avoided at all costs if you're not completely sure what you're doing -- that applies to me, at least. Filtering on the outbound also catches traffic from the firewall itself (complex scenarios) and could get you into a frustrating situation where your tunnel drops and the firewall can't get DNS to bring it up again if you didn't set it correctly. I made this a few days ago, maybe it can help: https://forum.netgate.com/topic/146714/tunneled-isp-cheat-sheet :)

And edited the title Thanks again for all your help and time, Much appreciated

I'd suggest you to grab a spare box and perform the update there / restore your config to make sure everything is going smooth. Risky to upgrade from a very old version with just one box if you run critical stuff there. -Rico

I don't get rude, I stated that I not able to help, if I don't get answers to my questions and you don't heed my advice. @w0lverine said in VPN Interface can't ping LAN interface hosts: I need to replace push "route 10.9.0.1 255.255.0.0" That option is handled by the "IPv4 Local network(s)" section in the GUI. However, that option is only visible if "Redirect IPv4 Gateway" is not ticked. Having that ticked and add a push route command into the custom options may end up in an odd behaviour. @w0lverine said in VPN Interface can't ping LAN interface hosts: To clarify I did more than just above: One time with default - Successful ping Openvpn as source - Failed ping If that is the case, there are two possible reasons: The pfSense is not the default gateway on the host. The host blocks access from outside its own subnet. If that's the case you have to solve it on the host.

VPNs utilize port sending administrations too. Much the same as your switch turns into the interface between your PC and the web and doesn't give the PC a chance to contact the web legitimately, VPN servers additionally utilize port sending to ensure a customer doesn't cooperate straightforwardly with the web.

A site-to-site arrangement is the place (at least two) distinct systems are associated together utilizing one OpenVPN burrow. In this association model, gadgets in a single system can arrive at gadgets in the other system, and the other way around. The execution of this is, similarly as Access Server is associated with this, generally basic

@seramis said in IOS 12.4.1 error connecting on pfsense OpenVPN setup server: 2019-09-18 15:35:05 EVENT: RESOLVE 2019-09-18 15:35:05 Contacting [192.168.1.2]:1194/UDP via UDP You need to connect to your public IP. In the log it shows that you are connecting to 192.168.1.2, which is your local IP within your network. This is not reachable from the outside. You need to change this either to a static IP which has been assigned to you by your ISP or (recommended option) use a DynamicDNS service (e.g. freemyip.com).

If the concerned LAN users have static IPs you're fine. @Jonesc said in Multiple OpenVPN Connections For Different LAN Users: If I was to add multiple 3rd party OpenVPN connections using their config profiles. Presumed you have already assigned interfaces to each connection, you can now add policy routing firewall rules, one for each user, where you can select the respective VPN gateway to direct packets to.

... or take the OpenVPN using the horrible TAP out of the equitation.

@bcruze shows me the access point of my vpn connection.

Double posting anyway https://forum.netgate.com/topic/146813/unable-to-on-outlook-after-connecting-open-vpn -Rico

@viktor_g Here it is with some of the names redacted. [image: 1569494879732-a16d73d2-ab19-4554-b15d-077947174fce-image.png]

@JeGr said in OpenVPN auth via Samba4-ADS / LDAP: @sgw said in OpenVPN auth via Samba4-ADS / LDAP: the "CA(-chain)" ...? Yeah but your ca.crt should have that. You can always check whats inside the PEMs but from the file size I would guess those are both 2k certs. And if there would be an intermediate to chain, it possible would be inside the ca.pem as well - or all certs (the whole chain including the host cert) would be in cert.pem. That's what's normally done with certain services. all in one or ca-chain in a separate file. I am not quite sure what to do or check now ;-) From the fact that it works sometimes it should be ok mostly, right? What I did today: added the two DC-IPs as NTP-servers to pfsense ... to make sure there is no time drift.

Forgot to attach some logs. These are from the server, log level 4: Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ] Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> SENT CONTROL [ripdog]: 'PUSH_REPLY,route 192.168.178.0 255.255.255.0,route-ipv6 <snip>::/64,tun-ipv6,route-gateway 10.1.0.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fe80::1000/64 fe80::1,ifconfig 10.1.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1) Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> PUSH: Received control message: 'PUSH_REQUEST' Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> MULTI: primary virtual IPv6 for ripdog/<android IP>: fe80::1000 Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> MULTI: Learn: fe80::1000 -> ripdog/<android IP> Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> MULTI: primary virtual IP for ripdog/<android IP>: 10.1.0.2 Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> MULTI: Learn: 10.1.0.2 -> ripdog/<android IP> Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_4a096a81963c2dc7629027cfc8e3c7ca.tmp Sep 25 16:59:55 openvpn 66643 ripdog/<android IP> MULTI_sva: pool returned IPv4=10.1.0.2, IPv6=fe80::1000 Sep 25 16:59:54 openvpn user 'ripdog' authenticated Sep 25 16:59:54 openvpn 66643 <android IP> [ripdog] Peer Connection Initiated with [AF_INET6]::ffff:<android IP>:4730 (via ::ffff:<pfsense IP>%pppoe0) Sep 25 16:59:54 openvpn 66643 <android IP> Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Sep 25 16:59:54 openvpn 66643 <android IP> TLS: Username/Password authentication deferred for username 'ripdog' [CN SET] Sep 25 16:59:54 openvpn 66643 <android IP> PLUGIN_CALL: POST /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.8 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_TCPNL=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_COMP_STUBv2=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_COMP_STUB=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_LZO=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_LZ4v2=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_LZ4=1 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_NCP=2 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_PROTO=2 Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_PLAT=android Sep 25 16:59:54 openvpn 66643 <android IP> peer info: IV_VER=2.5_master <snip TLS> Sep 25 16:59:54 openvpn 66643 <android IP> TLS: Initial packet from [AF_INET6]::ffff:<android IP>:4730 (via ::ffff:<pfsense IP>%pppoe0), sid=91b4984b ce8c5424 Sep 25 16:59:54 openvpn 66643 <android IP> Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-client' Sep 25 16:59:54 openvpn 66643 <android IP> Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-server' Sep 25 16:59:54 openvpn 66643 <android IP> Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] Sep 25 16:59:54 openvpn 66643 <android IP> Control Channel MTU parms [ L:1621 D:1172 EF:78 EB:0 ET:0 EL:3 ] Sep 25 16:59:54 openvpn 66643 <android IP> Re-using SSL/TLS context Sep 25 16:59:54 openvpn 66643 MULTI: multi_create_instance called There's nothing interesting on the client logs, they're very short.

I could solve the problem. Seems that is an issue between opnsense and pfsense. I installed an pfsense box on the other site and now it works. Thank you for your time!

@Rico [image: 1569309103945-1.jpg] [image: 1569309103972-2.jpg] [image: 1569309104005-3.jpg] [image: 1569309104034-4.jpg]

So uh... I totally disabled the VPN in order to be able to actually upload anything. Screenshot fail! Should be a little more enlightening here... [image: 1569284230474-img_2374.jpg]

That does sound similar. However, that bug report is 18 months old and hasn't had any replies or movement at all.