Singel interface Bridged OpenVPN server
-
Hi!
Got a weird ass config going here. Trying to get OpenVPN TAP, bridged solution for clients, with a single interface pfsense.
1.1.1.0/24 are public addresses. No NAT only routing is involved.
[internet] –-> GW 1.1.1.1/24:1194 and 1195 --> pfsense 1.1.1.150:1194 and 1195
The GW (no control over this one except if I ask politely they've opened the UDP ports for me) only lets UDP 1194 and 1195 through into my pfsense 1.1.1.150
I've got a fully working solution with a routed TUN OpenVPN on UDP 1194 for the clients. So that's nice.
What I need the client to get an IP from the 1.1.1.0/24 subnet so traffic from them is able to be routed out again through the GW 1.1.1.1. There are resources, say 1.1.2.0/24 which only are accessible if the traffic originates from 1.1.1.0/24 and other "internal" public addressed subnets.
Setting up everything like I thought it should work gives me an warning on the OpenVPN client.
WARNING: --remote address [1.1.1.150] conflicts with --ifconfig subnet 1.1.1.160/24 on interface -- local and remote addresses cannot be inside of the --ifconfig subnet (silence this warning with --ifconfig-nowarn)I understand the problem but can't think around it obviously. ::)
Is it even possible to get Bridged OpenVPN clients with only one interface active in pfsense?
Brgs,
-
What I need the client to get an IP from the 1.1.1.0/24 subnet so traffic from them is able to be routed out again through the GW 1.1.1.1. There are resources, say 1.1.2.0/24 which only are accessible if the traffic originates from 1.1.1.0/24 and other "internal" public addressed subnets.
This can be achieved by NAT as well.
Is it even possible to get Bridged OpenVPN clients with only one interface active in pfsense?
Don't know. But if you think twice, it seems to be plausible. It will not be possible to route the OpenVPN servers address over its own VPN.
-
What I need the client to get an IP from the 1.1.1.0/24 subnet so traffic from them is able to be routed out again through the GW 1.1.1.1. There are resources, say 1.1.2.0/24 which only are accessible if the traffic originates from 1.1.1.0/24 and other "internal" public addressed subnets.
This can be achieved by NAT as well.
By using NAT on the the routed OpenVPN connection, all client OpenVPN clients will originate from the the same, accepted IP, address. It's a solution, but I would like to see that each client poses with a unique IP (They've got some medical software which backtracks the clients IP and connects back to the client)
Is it even possible to get Bridged OpenVPN clients with only one interface active in pfsense?
@viragomann:Don't know. But if you think twice, it seems to be plausible. It will not be possible to route the OpenVPN servers address over its own VPN.
In bridge mode that shouldn't be needed I thought. PPTP (I know it's awful) handles this rather nicely. PPTP is the current VPN I try to get rid of here.
I've actually got a pfsense (2.2.6-RELEASE (amd64)) with PPTP server running on a singel interface. PPTP-server IP is a separate IP in the same subnet as pfSenses IP. Then I got a defined range of client IP-address also within the same subnet. Clients who connects appears with unique IP and works as I would like to see the OpenVPN bridge clients do.Brgs,
-
By using NAT on the the routed OpenVPN connection, all client OpenVPN clients will originate from the the same, accepted IP, address. It's a solution, but I would like to see that each client poses with a unique IP (They've got some medical software which backtracks the clients IP and connects back to the client)
You can use outbound NAT to translate a whole subnet. So you can get a unique IP for each client as well.
E.g. the VPN tunnel network is 10.10.10.224/27, outbound NAT can translate it to 1.1.1.224/27. To wit 10.10.10.228 will be translated to 1.1.1.228 , 10.10.10.229 to 1.1.1.229 and so on.
What's the problem with this???
