Hi
yes i know it a project that i m working on it with the API fauxapi and how to creat a VPN, users and filter by the API

Tried a web search?
The first hit brings the solution: https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-vpn-connectivity-to-a-high-availability-secondary-node.html

@JKnott I don't know why but I couldn't get the router without an internet connection to work. After starting from scratch creating a pfsense server and pfsense client tethered with the iphone everything works. BTW I can ping in both direction with the iphone on a pvt network. Thanks for your help I learned alot.

@grateful
Thanks for reply. Glad to hear that it works now as it should do.

Make sure to run the latest pfSense and openvpn-client-export package version.

-Rico

Hi Rico,

Tried anything without look.

Within openvpn i can access my lan resources (connected to pfsense gateway) but i was not able to access resources inside a remote LAN (LAN part of another department not under my administration), and they are not blocking me.

I pushed the route and i can see it inside my routing table, but there is no ping o DNS response

Any other idea?

Thanks

@Brow98n In what scenario am I attempting to set 2 default routes? I am thinking an assumption was made here, probably due to my bad explanation of the problem.

When I log in twice with the same user it is from different machines as I would not be able to easily determine which tunnel was broken. I do not have OpenVPN overwrite the default route on the client, I just advertise routes to specific endpoints inside my networks. I do not believe that OpenVPN easily supports a per user route advertisement, AFAIK, it is a function of the OpenVPN instance. In the end, if I can give routes to device list A to user list A and device list B to user list B, that would accomplish my goal of 2 instances, and work around my issues I have on the second instance.

Hi,

All the trick resides on Phase2 entries and Openvpn Remote networks setup.

Let's start on OPENVPN config.
You should configure OPENVPN Server Tunnel Settings like this

openvpn.png

And now let's go for IPSec
I will assume Phase1 is connecting properly
You should add a new Phase 2 entry for injecting OPENVPN traffic from clients to IPSec remote network
The final picture will be something like this
ipsec general.png

Just add a new P2 for IPSec traffic

ipsec p2.png

And finally check Rules on OpenVPN and IPSec interfaces to let traffic flow
Here we have an example of what we have in a customer. There are restrictions of traffic getting through the tunnel to the IPSec remote network
IPSec rules.png

And we have full acces from OpenVPN clients
OpenVPN rules.png

We have all NAT outbound set as default
nat outbound.png

When connected, in Status - IPSEC - Overview you should see something like this
Status IPSEC.png

When testing connection, just send a ping from OPNVPN Subnet (you can use your pfsense OpenVPN box IP as source IP) and check on status if packets-out increases. If they do, you are injecting OpenVPN traffic through IPSec tunnel.
If there's no response, check other side firewall and settings.
We had a strong headache with a provider that did not set rules properly on their side.
But if there is increasing Packets-out count, you're sending the traffic properly.

Also note that when doing traceroute from OpenVPN client subnet you will have a "strange" response.
It will be something like this in your case, assuming remote IPSec gateway public IP address is 203.0.113.10

Traza a 192.168.0.15 sobre caminos de 30 saltos como máximo. 1 7 ms 6 ms 7 ms 172.26.200.1 {pfsense OpenVPN IP address) 2 79 ms 77 ms 77 ms 203.0.113.10 {IPSec remote gateway public IP)} 3 78 ms 78 ms 77 ms 192.168.0.15 {remote ip}

That's correct and traffic is tunnelled inside IPSec.

Hope this helps.

@paulparisi said in Accessing OpenVPN Connected Devices:

Is there a better way to do this?

Probably not. You could hand out addresses via RADIUS but either way it's manually managed.

Is there a way to have a full DHCP server on the OpenVPN private network?

Not in any meaningful way. You could bridge the VPN to a local interface with a DHCP/DNS structure, but that has other drawbacks.

Well, it appears to be that the pfSense GUI is simply hiding the IPv4 Remote Networks option that I need to set on the main page, since I've selected a "Remote Access" mode. This is somewhat disappointing since that isn't even an OpenVPN "thing", just a pfSense "thing" to determine what GUI options to show and what options to hide.

Guess I'm off to file a bug report / feature request to ask that we get a 5th "type" option for OpenVPN servers called "I know what I'm doing, don't hide any options from me."

In the meantime for anyone running into this, I think the only way to address it without having to create a separate server on another port so you can get run it as "peer to peer" is to assign an interface to the OpenVPN instance which you can then use to assign a gateway and a static route in the main pfSense routing configuration.

Ugh.

@Rico said in OVPN export to iOS fails:

Yeah NM, I see Gertjan is also using udp4 in the config like TO.

You bet it is !
I'm actually VPN-into-work just to get my iPhone 'multistacked' ^^
All this over an UDP IPV4 link of course.

I ended up resolving the issue. Only used the local Windows DNS server for the OpenVPN configuration. Viscosity setups up this loopback to internally handle the DNS itself.

@sreyas

On the server configuration page, you select the protocol and local port. You'll then have to run client export again.

@q54e3w

On the server side, I assigned the IPv6 Tunnel Network prefix. I also selected Redirect IPv6 Gateway, though that depends on your needs.

In Advanced Configuration > Custom options, I added push "route-ipv6 ::/0".

I also added that on the Client Export page, though I don't know if both are necessary.

@JKnott @Pippin Thank you very much! I have been putting this off due to a lot of dhcp reservations, but find and replace, in the xml export, reimport and reboot made it fairly easy to migrate to a subnet less likely to cause me conflict.

Thanks that was the problem.

Great! Many thanks for clarifying that :)