anyone have experience with OpenVPN Bridge? What I would like to know that if
I setup OpenVPN Server on Linux machine which the LAN is on 169.254.1.xxx
on the LAN (of that server) I have a computer that is on 169.254.1.2
Have a OpenVPN client on OpenWRT which the LAN is also on 169.254.xxx and assuming would get 169.254.1.5 (ip assigned by the server I assume)
And that I have a "device" on the router which I would think the IP of that device need to be statically programmed, such as 169.254.1.1 and use router's 169.254.1.5 as gateway
So with this setup, is there ANYWAY the computer at 169.254.1.2 can access 169.254.1.5?
My personal take would be NO, right? Or is it possible? Because 169.254.1.1 (that device) does NOT have openvpn client installed, it is simply "attached" to the 169.254.1.x network via the router, thus is not broadcasting to the server. So how would OpenVPN Server know that it exist, no?
The reason I ask is that someone is asking me about this setup and I just don't see how it will work...
Right off the bat, this seems strange. The 169.254 addresses are part of the automatic IP address assignment process that happens when a DHCP server is not available. Many operating systems will treat this as a broken network.
You should use RFC1918 addresses. (i.e. part of any of these ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Meanwhile, OpenVPN can run in two modes: TUN or TAP.
TUN is a routed method, so an L2 bridge cannot be used on a TUN device. All OpenVPN clients can support TUN.
TAP is a layer 2 network device and that can be bridged. However, this is generally considered an inefficient transport method (vs TUN) because all layer 2 broadcast and multicast traffic will traverse the tunnel, potentially causing congestion and network slowdowns (especially if the TAP link itself is bandwidth limited). OpenVPN TAP support is not available on mobile OS's (they only support TUN), and may or may not be available on desktop class OS's. TAP is generally being phased out.
Rather than starting with the solution, let's go back to what the goal is... can you describe the purpose of this VPN connection and any constraints present?
Ya, I understand that, I did told the client about that were 169.254. is best not be used because alot of router and firewall won't even route correctly with that, but for some reason they told me their hardware is hard coded that way.
The goal is that
They have a "software" that runs a web server (the "software") that is on 169.254.1.2 (hard coded according to them).
This software will be running on the same "network" as the OpenVPN server, which means the "software" is running on Windows and on the same Windows OS, they probably will run OpenVPN server too.
And then they have a "remote" device which DOES NOT have capability of running OpenVPN Client. thus this "device" will be connected to our router, which we do have OpenVPN client (OpenWRT OpenVPN client).
Now comes the HARD PART, they said that their "device" is also Hard coded on 169.254.1.1
So originally, what they had was that this "web server software" (which runs on windows computer) is actually DIRECTLY connected (via network cable) to this "device" thus is easy to work and communicate that way. But now they want to "seperate them" into 2 locations. So they need "somthing" in the middle" to be able to make these 2 "think" that they are STILL ON the same network... And on top of that the software (169.254.1.2) and the "device" (169.254.1.1) are both hardcoded and you can not change the IP...
And the weirdest thing which they can not explain to me is that they want "multiple' of these 169.254.1.1 device connect back to the "software"? But how is that possible? If they are all on 169.254.1.1, wouldn't there be like a total IP conflict all over the place?? But then they said something about once the link is up, they don't communicate via IP?? I ask them if is MAC, they are not sure either... but that would be another problem I guess. Because I can't even see even to get just 1 to run...
Your client needs to seriously reconsider the whole approach. Any device or software that is hard coded with an APIPA address in general is of dubious worthiness from a networking standpoint.
If they have overlapping IP addresses, it's mostly game over.
I mean, it might be possible to get something to work using a bunch of intermediate devices each with NAT and port forwarding, but now you're dealing with routing again anyway.
Can you draw a network topology diagram about how this is supposed to work?
I feel like they are pulling my leg and wasting my time. I just want to make sure that with OpenVPN bridge, device that is behind the client, server can see, because if it can't, I would simply tell them that they have to look for other solution... Thank you for you time.
I can see that the router 169.254.1.5 can broadcast to 1.2 as it is a openvpn client, but the 169.254.1.1 (the "device"), I don't see how 169.254.1.2 can see it exist? Because 169.254.1.5 wouldn't "tell" 1.2 that "hey I got 169.254.1.1 behind me"? no? And if it does, and when he got multiple of these 1.1 device, they would all be conflicting...
In general, I'm going to say that this is going to be really hard or impossible.
That diagram is certainly missing a lot of detail... I know that's not your fault.
Where is the internet connection on each of these devices (there's got to be something that connects them to the internet) and what is the addressing there? Where would an OpenWrt router fit in this diagram? And how do the 'multiple of these' factor in -- are they all at one site? Do they all go through the same modem or are there different modems? Do they all connect to the same primary internet connection, and if so, how? If they are at different sites, how are they connected and addressed... lots of questions.
I was able to get into the "device" using port forwarding and SNAT (because the device will only accept data packet that is on the same network). The router is a wireless cellular router. So, originally, the forwarded packet had the source IP of public ip of the originator. But using SNAT I was able to change the source IP to be on local network. But the problem is that on the "web server software" they said that it is "hardcoded" to talk to 169.254.1.1 and can not be cahnged... so it throw that idea out the window....
Whoever hardcoded the web server software address had bad judgement. Whoever specified that it should be on an APIPA address range should not be allowed to write networked code or be involved in the development process in the first place.
ya, no sh**... I have no idea what they are thinking. So I think I am just going back to client and say they have to come up with something else... THANK YOU VERY MUCH for your time though to verify my thought. I do alot of OpenVPN network but just never try to do a layer 2 bridge before. But even at that, I wouldn't think a "device" that does NOT have client can be seen by the OpenVPN server. Unless, like you say, probably do alot of micky mouse routing? I think the easist way is to be able AT LEASE change the target IP in their "web server" softrware that is NOT hardcoded to 169.254.1.1. This way, they can point the web server to the PUBLIC IP of our router (it is running on a STATIC PUBLIC IP SIM) and then we can FOWRAD the packet to the "device" (I had set the router to be on 169.254.1.100).
here is a simple (sorry for the roughness, I just did it quickly right now) diagram which was working, only if their web server (on the 169.254.1.2) can allow to point to OpenWRT's WAN IP of 166.5.5.5, then it would work without needing the VPN, I did a simple port foward with SNAT and I was able to get into the 169.254.1.1's web login interface.
My guess is that this controller system was designed to be air-gapped and physically local. It probably assumed that there would be no other network connections whatsoever and that there wouldn't even be a DHCP server in the network. In fact, it's probably assumed that it is a 1:1 computer:controller setup where the computer could have instead been connected via serial except for possibly limits on the cable length to allow the computer to be physically distant from the controller equipment. I could see this conceptual basis justified for an industrial process where the computer is in a control room hundreds of feet away. But, this would have been a very very shortsighted design decision by the equipment manufacturer as it doesn't allow these devices to be networked in any sensible way.... and maybe that was intentional if they wanted to ensure it would always be airgapped and never connected to any other systems. But still, bad design.
so just to be sure, in your experience, this is probably not doable by a simple OpenVPN Layer2 bridge as specified correct? Because when I tried to setup a OpenVPN server on 169.254.1.xxx network (weather be on Windows or firewall such as pfSense), I couldn't even get it to route right. When I setup the nic interface on pfsense, it won't even route packet out of to WAN.
I don't think a L2 bridge will work, no. But honestly, I have no idea because the system as described just isn't really compliant with normal networking concepts.
You could try it with a little lab network where you could setup 2 OpenWrt routers with lans in the APIPA subnet and then try to bridge them together with an OpenVPN tap configuration. It's plausible that it could still function. But, this would still be a 1:1 setup. I don't see any way to have multiple controller devices on a single connection or network if there is an address overlap.
Thank you again. Ya I am going try a bit more but most likely I will tell them they have to re-design or else is going to be hard to continue this project....
