OPNsense Forum
Archive => 21.1 Legacy Series => Topic started by: verasense on April 02, 2021, 02:29:01 pm
-
This should be an easy one, but I can't make it work.
I am trying to connect as a client to the OpenVPN server. What I want is to connect as if I was in one of my VLANs, transparently, let's say 192.168.3.0/24, and get an IP address from there as everyone else in the network.
So I use:
IPv4 Tunnel Network = 192.168.100.0/24
IPv4 Local Network = 192.168.3.0/24
Dynamic IP unchecked
Address Pool checked
Topology unchecked
However I always get a 192.168.100.0 IP address and I am not able to access the VLAN. How can I configure this?
-
Create a firewall rule on the tunnel interface to allow hosts in the tunnel network to access the VLAN network
-
Mmm.. But this does not give me an address in the VLAN as if I was another member of the VLAN...
And this then I suppose is not relevant: IPv4 Local Network = 192.168.3.0/24
Another point that makes this solution not valid for me is that there are some devices broadcasting their service, and even though the VPN client is allowed to access the 192.168.3.0 network and ping the device, it does not get the needed broadcast packets.
-
No, because the VPN host is not part of the VLAN network, it is part of the tunnel network
Maybe I have been missing something fundamental for years, but I have never run a VPN (OpenVPN or WireGuard) that achieved what you are asking :)
-
Actually, digging in to this a little more, it seems theoretically it is possible if you implement bridging in OpenVPN: https://www.grc.com/vpn/routing.htm. As to whether this is possible in OPNsense, idk
Edit: more info: https://openvpn.net/community-resources/ethernet-bridging/
-
Looking at the OpenVPN settings in OPNsense, it you select tap as the device mode rather than tun, you do get bridging options... I have only ever run OpenVPN as tun. TIL
-
Is there no other way than tap? I suppose many people run IoT devices on a different VLAN, and many devices don't use mDNS but only simple broadcasting... There must be a way.
I always thought VPN could make you part of the internal network, using the same DHCP and policies as if you were connecting via a LAN cable.
-
Well, a broadcast domain is layer 2, so you need a layer 2 solution. There are other options such as gretap that could be used over OpenVPN tun, but that would be wasteful compared to just OpenVPN tap
-
I will check tap and get back here.
By the way, does it make sense that when I use as source "VPN net" the rule is not triggered at the firewall but when I use the VPN net explicity (192.168.100.0/24) it does?
PASS IPv4 VPN net * * IOT net * * * --> Not triggered, so next rule blocks access
Log:
ovpns1 Apr 2 15:58:16 192.168.100.6 192.168.3.200 icmp Block VLAN
PASS IPv4 192.168.100.0/24 * * IOT net * * * --> Triggered
Log:
ovpns1 Apr 2 15:58:41 192.168.100.6 192.168.3.200 icmp
I thought "net" means every host in the VPN network
-
Unfortunately, TAP mode is not supported on Android OpenVPN.... : ( So not a solution for me.
I wonder how people do this... to check IoT devices away from home via VPN. Many of them don't use mDNS so there must be a way.
-
Unfortunately, TAP mode is not supported on Android OpenVPN.... : ( So not a solution for me.
I wonder how people do this... to check IoT devices away from home via VPN. Many of them don't use mDNS so there must be a way.
Maybe they are using a central smart home server which is accessible over L3/IP
-
By the way, does it make sense that when I use as source "VPN net" the rule is not triggered at the firewall but when I use the VPN net explicity (192.168.100.0/24) it does?
There is a similar issue with “WireGuard net” when OPNsense has multiple WG local peers or endpoints. The “alias” does not behave as expected. Best to define your own as you have found
-
BTW, this is probably a long shot, but have you looked into whether the udpbroadcastrelay plugin works across VPN interfaces?
-
BTW, this is probably a long shot, but have you looked into whether the udpbroadcastrelay plugin works across VPN interfaces?
I was exactly looking into this before reading your post.
I came along to this post:
https://forum.opnsense.org/index.php?topic=15721.0
And I installed the plugin. It seems to do what is expected, but the device is not answering me back...
-
Afaik you need a fw rule back from the device to the tunnel. See the comments that the plugin author makes in that thread. Also here at the bottom: https://github.com/marjohn56/udpbroadcastrelay
-
Yes, I think I have my rules OK. I was in the Live View and capturing packets on the interface (that's how I saw that the UDP packet was correctly delivered) but I did not receive any response from the device. I thought that maybe it's because the packet came from another network, not from its same LAN. Then I changed the "source" in the udpbroadcastrelay plugin to an address in the same LAN, and I could see the packet was forwarded with the "spoofed" IP. No answer either.
So I have no idea at the moment. I will continue tests tomorrow since I opened the firewall to let the device connect to its external server and now the apps have learn the device IP, so everything works even if I enable the firewall. However, after some time they will forget the IP again and I will have the same problem.
That is why being able to VPN into the same local VLAN was the easiest for me.
-
I have analysed the packets from a computer on the same LAN as the device and from a computer in a different VLAN with udp broadcast relay. The only difference I see is that the legitimate one sends an additional broadcast packet to 255.255.255.255 (apart from X.X.X.255). However, I can't use these broadcast IPs on udp broadcast relay because it marks them in "yellow" colour instead of "green", as if they were not valid.
-
Hi Verasense,
Sorry it's almost two months ago that you were working on this. I'm late, but looking for the same solution. I have used udp-broadcast-relay to forward udp broadcast and multicasts across two internal vlans. This allows me to run both apps in the "other" vlan quite well! and it's all routed, no bridging. This is perfect.
So I also want to do this for an OpenVPN client. I've fooled around with creating some very basic firewall rules, but so far I can't seem to get it to work. Have you had any more luck?
Thanks!
-
I updated to 21.1.6 and it's behaving a bit differently, but still not working.
I created an interface assignment for OpenVPN (which is required for udpbroadcastrelay) and I name this assignment something unique that doesn't match the existing OpenVPN firewall rule. I of course add another rule for the new assignment, which allows the OpenVPN traffic.
In 21.1.5, the line in udpbroadcastrelay would turn white (which I believe means it's illegal). With 21.1.6, it doesn't go white, but with a little bit of testing, it doesn't seem to work. I've not scoped it yet, but it does seem to be a bit closer to working.
-
Hi. I'm hoping to generate interest here, but maybe I'll start a new thread? I'd like to thank Greelan and especially marjohn56 for their work on udp_broadcast_relay -- from here on, I'm calling it UBR to make it easier. This is an especially useful thread >>
https://forum.opnsense.org/index.php?topic=15910.0
The goal here is to get UBR to work with vpns - in this case OpenVPN. Yes TAP bridged connections and GRE over ipsec are available... not great, and not exciting. :-)
When I create an OPNsense interface for OpenVPN (which seems required for the UBR gui tool) -- the individual line goes white-out... which from other testing I believe means it's an illegal config.
I was surfing on UBR and VPN and found these two posts (the second is FreeBSD code) >>
https://community.roonlabs.com/t/talking-to-roon-from-another-vlan-i-got-it-working/119840/12
https://github.com/synfinatic/udp-proxy-2020/releases/tag/v0.0.4
Glad to help out with testing. Hope this is an exciting topic for others! Thanks!
-
Thanks, but I can’t claim any credit for UBR. All marjohn56’s work.
-
Hi Greelan - it's funny how sleeping changes how you look at something.
When I last posted, I was thinking that marjohn56 might "add vpn support" to UBR, which "could happen" but with today's eyes, and the benefit of coffee, it's probably more likely to just ADD udp-proxy-2020 to OPNsense.
Briefly, how difficult is this to do? Is is something a newbee could do?
Is there a more-formal way to request new code to be converted into an OPNsense package?
THANKS Greelan!!
-
missed latest update >> https://github.com/synfinatic/udp-proxy-2020/releases/tag/v0.0.7
Aaron is running udp-proxy-2020 on pfSense himself, and he's looking for help on creating a "proper package" -- I bet he'd be ok taking his work into OPNsense. I'd love to help but I'm more like Homer in that gif.
udp proxy into vpn..... priceless.