Hi,
I’ve installed IPfire and activated openVPN, my network is so composed:
I have the ISP router (192.168.1.1) where I opened the port for remote connection to the VPN, then there is the IPfire (RED: 192.168.1.254 GREEN: 192.168.0.1) that is connected to the router and via a switch (which is linked to IPfire GREEN), I’ve connected several devices including a DVR (192.168.0.83).
I succeed in connecting remotely to the VPN via noIP but I can’t access to the local devices except IPfire itself. When I’m connected from the RED (therefore from PC 192.168.1.10) I can access all the local devices.
Actually is not a problem. Is working as intended.
My bad, i read wrongfully. So.
VPN devices usually are on a different subnet than Green or red one. Some prefere to use “bridged” but I suggest against that (more on that later).
Step1: IPfire should be instructed to allow connection from VPN to green. Firewall rules
Step 2: the device on green segment could/should be instructed to allow connection from VPN segment. Most of devices/OS allow connection because come from the firewall IP, which is in the same subnet. However, due to routing, could not be take as granted
Step 2-bis: device must have IPFire as gateway. This is a prerequisite to work “more correctly” via VPN
Step 3: protocol should allow routing. You can’t WOL from VPN to LAN (mostly… there are some caveats about that)
Last but not least: why VPN routed is far better than VPN bridged?
Anwser is: control. With routed VPNs you can create specific rules for any remote client, without doing crazy things and without create multiple endpoints/“VPN Servers” for every “kind” of client.
2-bis. All the devices on the green have IPfire (192.168.0.1) as gateway as you showed me in step 2-bis.
I still have some doubts about step 2 and 3:
What do you mean by step 2? How can I instruct the device on the green segment to allow connection from VPN segment? I created a rule from the device on the green to the VPN segment, is it okay?
What do you mean by “you can’t WOL from VPN to LAN” in step 3?
If it’s windows, you can define into Windows FIrewall that connection from 10.44.209.0/24 are allowed.
Simple example.
WOL (wake on lan) is a protocol based on phisical level, so from OpenVPN client you cannot send any WOL traffic, because the network is phisically different.
I think this is the problem (good thinking in doing this test). Your ISP’s router is probably interfering when accessing OpenVPN from the WAN side of your provider’s router. This is self evident when this problem disappears if you still access OpenVPN from the WAN side of IPFire, but AFTER bypassing the provider’s router.
Did you put IPFire in the DMZ of the provider router (if it is possible)? This should remove any firewall rule restriction in you provider router. Furthermore there are routers/modems that have this modality called “IP passthrough” or “half-bridge”. You define somewhere in the router the mac address of the IPFIre machine in the DMZ and all the incoming traffic will be forwarded to IPFire, without double-NAT (see below).
Next, what about a Port forward to UDP 1194 (you said yes, but just to be sure)?
If both these conditions are met, you could have some funny business happening with a double NAT. In this case, you are SOL. Double NAT occurs when multiple routers on a network segment perform Network Address Translation, leading to translation happening twice before data reaches its final destination, potentially leading to routing complications and making it difficult for devices on separate subnets to communicate with each other.
About IPFire “allow” rules, they should have been created automatically by IPFire when you configured OpenVPN. I do not have them and still everything works out of the box. As they do for you, which is evident when you do the test I quoted above.
I’ve tried remotely (WAN) from Windows and IOS too but still doesn’t work (I can’t ping nothing else than IPfire on LAN). If the problem is that one you showed me, why can I reach local devices when the client is connected to RED?
And what about the WOL, what should I do in your opinion?
do you have the possibility to enter an IP passthrough? It looks like a rule where you define the MAC address of a machine in DMZ as the destination of incoming traffic.
EDIT: searching the Italian web I found this (horrible) tutorial. From there it looks like it is possible to activate an IP passthrough with TIM. Basically, it’s similar to a port forward, but it applies to all traffic.
the logs of the router would be useful, if you can access them, because they would allow to figure out what happens to the traffic from the green network behind IPFire.
Yes, I added IPfire’s MAC address to the router’s DMZ, then to make sure the DMZ was working, I removed the port forwarding related to the VPN and tried to connect remotely to the VPN and it worked.
I have one more question: if it was the router blocking the traffic, why can I access remotely from VPN only to IPfire via SSH and not to other devices on the green segment (e.g., a raspberry pi)?
EDIT: I tried to ping from a PC connected to the VPN remotely towards all the hosts in the GREEN segment and it was successful, furthermore on the Raspberry I have an Apache web server which I can access, but if I use the ssh protocol or try to access the The DVR’s web interface still doesn’t give me any response. What could be the cause?
I suspect this is due to the MTU size because it happens when communicating further downstream IPFire, therefore needing more encapsulation and making the packet larger. From the main configuration page of OpenVPN try lowering by 10 units the MTU, restart OpenVPN and check the web site availlability from the remote client, keep repeating these steps until it works. I found by trial end error that a value of 1360 is well supported by most networks.
If you are not aware of this particular problem, you will find below a description of the reason why the MTU size is frequently creating trouble for IPFire users.
A too-large MTU (Maximum Transmission Unit) in a network pathway can compel routers to fragment packets into smaller units to align with a router’s lower MTU size. This not only increases overhead but reduces transmission efficiency as each fragment must be handled separately, thus creating a bottleneck.
The issue amplifies when VPNs like OpenVPN are involved because encryption adds to the packet size. If the MTU is overly large, packets can overshoot the permissible MTU size post-encryption. Consequently, routers have to fragment these packets post-encryption, a step that demands the fragmented pieces to be reassembled at the destination before decryption can occur. This introduces significant latency and creates a bottleneck due to the added complexity in processing.
In particular, this can lead to fragment drops or out-of-order arrival, necessitating retransmission and complicating decryption. Moreover, fragmentation at an intermediate router possessing a smaller MTU can potentially fail since it lacks the requisite encryption keys to decrypt, fragment, and then re-encrypt the data, thereby contributing to the transmission issue.
IPFire is part of the appliance routing table while the RPi IP Address should be unknown to the border router as it is assigned by IPFire. Maybe it would have needed a static route in the provider’s router? However with OpenVPN in the mix I am not sure this is even relevant.
The truth is that I simply do not understand the routing system well enough to answer your question, particularly considering the complexity added by the overlay of the OpenVPN server’s routing on top of the IPFire and commercial appliance routing.
However, a potential explanation could be unrelated to routing issues. It might be that the packet size, when hopping from the OpenVPN servers, exceeds the MTU size that the routers can handle, thereby creating a significant bottleneck that severely impedes the packet flow. By removing one hop with an half-bridge, you made the packets smaller and therefore avoiding this issue.
I prompted GPT4, and after few rounds, we obtained this summary which should be accurate. @ricc With this knowledge you should be able to further investigate your network behavior and see if you can figure out what went wrong before bridging your border router. If you discover anything useful, I would appreciate if you would report your findings here.
A client from the WAN side wants to send a packet stream to a machine on the IPFire green network, with IPFire situated in a DMZ facilitated by a bridge via a provider appliance operating in Half-Bridge mode. Here’s a simple representation of your network topology using ASCII art, showcasing the involved IP addresses:
The client in the WAN has an IP address of 203.0.113.30.
The Provider’s Router operates in a half-bridge mode and connects to the IPFire system, which is placed in a DMZ zone to allow unrestricted access from the internet.
IPFire has two main interfaces: the RED one obtains its IP address dynamically through DHCP from the provider’s router, and the GREEN one, which has a static IP address of 10.0.0.1, connects to the green network.
The OpenVPN server is hosted on the IPFire system and is responsible for the encryption and decryption of packets flowing through it.
Inside the green network, there is a switch that facilitates the connection to various machines, including the destination machine with an IP address of 10.0.0.50.
The green network accommodates a range of IP addresses denoted as 10.0.0.x, where x is a variable defining different machines in the network.
Let’s go through the steps involved in this transmission:
Layer 2 (Data Link Layer):
Client Side (WAN): This is a simplified version which involves layer 2 and 3. The OpenVPN client, operating from IP 203.0.113.30, initiates a connection. It creates packets with a destination IP of the IPFire system (e.g., 192.0.2.2), which is the endpoint of the VPN tunnel.
Provider’s Router: This router receives the packet extracts the frame and forwards it to the next node in the path, which in this scenario is IPFire placed in the DMZ, bypassing any NAT that would normally occur. Later, the responding packets from the destination machine will travel back through this same path in reverse order, reaching the provider’s router from IPFire before being sent back to the client machine.
IPFire: IPFire receives the frame on its RED interface. It examines the frame and sends it to the corresponding layer 3 protocol for further processing.
Layer 3 (Network Layer):
IPFire: IPFire identifies the destination IP address (let’s assume it is 10.0.0.50 in the green network) in the packet header. Utilizing its routing table, it ascertains that the packet needs to be sent through the green network interface.
OpenVPN Routing:
OpenVPN on IPFire: Before IPFire forwards the packet to the green network, OpenVPN intercepts it. The packet is decrypted according to the VPN’s security protocol.
IPFire: IPFire processes the decrypted packet, modifying the IP header to include its green interface IP address (let’s assume it’s 10.0.0.1) as the source and the destination machine’s IP address (10.0.0.50) as the destination.
Layer 2 Again:
IPFire: Now IPFire creates a new frame with its green interface MAC address as the source and the MAC address of the destination machine (10.0.0.50) as the destination, embedding the decrypted packet inside this frame.
Green Network Switch: The frame travels through the green network switch, which uses the destination MAC address to find the appropriate port to which the destination machine is connected and forwards the frame to that port.
Destination (Green Network Machine):
Destination Machine (10.0.0.50): Upon arrival, the destination machine extracts the packet from the received frame and commences the layer 3 protocol stack processing, setting the stage for subsequent application-level data retrieval. The subsequent response will be formulated here and will be sent back to the client following the reverse of the path and encryption steps described.
This series of events effectively facilitates secure communication from a WAN client to a machine on the IPFire green network, leveraging both bridging and VPN functionalities to maintain security and data integrity during transmission.
Thank you so much for your explanation, you were so professional and helpful. The problem was due to the MTU, as you had suggested me. After many attempts I managed to find out that for my network’s configuration the ideal MTU’s value is around 1300, in effect, after this change I managed to reach remotely via VPN all the devices on the green segment.
Your advice was really useful!
Thanks a lot.
