@tig-ext said in OpenVPN email stopped working: @kiokoman Yep, I do get it, I was just pointing out that @Gertjan asked how I did it and when I pointed him to first post he replied "I know " This thread can be closed now, thanks for the suggestions Hi, Can you tell me your solutions?

Thank you for responding. After making the change, I now have many firewall entries between my SG-1100 and virtual IP address on the openvpn interface. Also from LAN hosts and virtual IP address on LAN interface. After updating the firewall rules, I still cannot ping the other hosts behind the LAN (172.20.1.3). I can ping them when connected to the LAN directly. I also turned off the firewall on the client.

There's no need to write out that commands into the advanced options box. You better use the "Remote Network/s" box for that. Just type in the networks which should be routed to the remote site.

I actually found instructions from Netgate on how to do this from one of their web presentations. Under firewall, NAT do a port forward rule: Interface: OpenVPN Protocol: TCP/UDP Destination: Invert Match checked, This Firewall (self) Destination Port Range: DNS (will be port 53) Redirect Target IP: 127.0.0.1 Redirect Target Port: DNS (will be port 53) This worked perfect for me and all Openvpn DNS requests are now encrypted with DOT. I actually duplicated this rule for all my interfaces/networks in case users try to use their own DNS servers over port 53, they will now be encrypted and sent over port 853 to cloudflare.

@kiokoman said in IPSec mobile clients connecting to OpenVPN site-to-site VPN: just press "thumb up" on the answer, the coffee would become cold :) Thumb up applied. Thanks again!

So you have a running OpenVPN server already and want connect to it from outside as well as from the guest VLAN? So assuming you're connecting to the server by using its FQDN hostname and that hostname is resolved to the WAN IP in the guest VLAN, you only need to add a firewall rule which permits that access. Just add a rule to the guest interface allowing the OpenVPN access to the WAN address.

@viragomann Perfect...I got it. Makes sense now. Thanks for the assistance!

I rly dont understand what the problem should it be... the only 2 devices that has to do the encription / handshake and so on is my computer that is asking the pfsense over lan for the encryption and the pfsense on my box. Now I see that I made the picture wrong... the encryption is only between my computer and the pfsense. the pfsense is just the represent one that is going over my other router outside. PC and pfsense are connected to each other over a lan cable... So only those 2 devices are necessary for the encription. Edited the picture

Thank you, @viragomann. That did the job! [image: MM2SWto.png]

Also, local IP printing to each of the printers works as expected.

Can you ping the cisco IP on your transit network from your vpn client? I can not tell from your diagram what the cisco IP in this transit is 192.168.0.1?? With pfsense IP being 192.168.0.254? Other than @viragomann great points.. Also don't forget possible overlap? What are you using for your tunnel network? What is the remote clients local IP.. If it overlaps 192.168.1 remote client would have any need to send traffic down the tunnel to try and get there. Also don't forget local firewalls on your dest box.. Not allowing whatever your tunnel network is. Which would be the source IP from your vpn connections. Can the vpn client ping the cisco svi on the lan side network 192.168.1.1?

@bcruze thanks for reference.

I didn't zero in on the fact that he was using pfSense nor am I too familiar with it. I'll have to get smarter on that.

Then you are doing it wrong. Not sure what else to tell you. Post your config screens. You are trying to match traffic sourced from VPN Net. Chances are that is not matching anything. Try changing those sources to any (like they are on the OpenVPN tab.)

If you are trying to port forward in from WAN across OpenVPN to a host there you must: Assign an interface to the OpenVPN instance on the target server side Be sure that the incoming connection there is NOT passed by a rule on the OpenVPN tab but IS passed by a rule on the assigned interface tab. This will get you reply-to there and the reply traffic will be routed back through the tunnel.

If they all use the same general settings you can put additional remote entries in the extra configuration settings at the bottom of the client configuration. remote host [port] [proto] Remote host name or IP address. On the client, multiple --remote options may be specified for redundancy, each referring to a different OpenVPN server. https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

That is not set by OpenVPN. That is set on the interface by the router. OpenVPN only provides the virtual interface which the router uses here. Some non-professional routers do the translating by default. Maybe you can disable it. Look for settings named like "masquerading".

It's strange that PFSense can't auto detect this- when I dump the route tables for my other VMs, they don't have a mapping to the VPN subnet either, but they are still able to talk to VPN clients. Anyway, this solution worked for me. Thank you.