Openvpn two way communications

Been using IPCop for at least the last 10 years or so. Recently switched to IPFire due to the MD5 certificate depreciation in Ubuntu 18.04 openvpn client.

I like the interface and features but have been fighting for weeks to get green ssh access to openvpn clients working. openvpn clients ssh to green works fine but I use the VPN for remote support of client systems (client connects and then I ssh into system, either from green network or from my own vpn connection using an ssh hop from green).

The firewall logs say ssh port 22 packets are being forwarded ( green, vpn)

ssh reports the connection refused (but the client is not refusing the request) and nmap reports all ports are closed.
I have tried:

Multiple vpn subnets and pushing client routes
static routs
multiple rules to open traffic between the vpn and other subnets
turning off all other firewall features
fresh install etc etc

If I swap back to IPCOP, everything is fine again. I cannot find any openvpn or IPFire documentation that states server access to client network resources is blocked. I have had this working as well in a pure openvpn install so its not openvpn.

Is this functionality blocked in IPFire? Can anyone point me in the right direction?

IPforwarding to ONE dedicated IP is working ! Semms “it does what you said”

  • did you really say what you want ? :wink:

Normally networks will be routed. So I can not understand your problem really.
Routing works (here) perfect with more than one (different) networks.
May be you have to pay attention to your networktopologie for easier work.


The problem had three parts (not all have been solved yet).

  1. NIC on green network was intermittent or has a driver issue. Was a pain to track down but once I swapped with Blue NIC, problem moved to Blue network.

  2. Testing incoming ssh machine had corrupt sshd and rejected all ssh requests. apt purge and reload solved this.

  3. Of the seven Ubuntu machines on my internal network, one was not always getting a default gateway via DHCP. With my luck this was one of the machines I was using for testing. I have not solved this problem yet, and have to add the route manually. This machine is identical to three other Ubuntu 18.04 machines, so why it is the only one not getting a default route is a mystery. I assumed this was a “rfc3442-classless-static-routes” issue but all machines have /etc/dhcp/dhclient.conf configured exactly the same.

I now have reverse ssh connections to openvpn clients working in certain circumstances. I will start a new post that is a bit more descriptive on that.