0

I have a remote office with a firewall running OpenVPN which clients can connect to.

Firewall interfaces:
* eth0 - 1.2.3.4 (public)
* br0 - 192.168.1.1 (/24)
* tun0 - 192.168.254.1 (/24, VPN clients)

So VPN clients, 192.168.254.0/24, can see 192.168.1.0/24 though they don't need to. But I do need 192.168.1.0/24 to talk to VPN clients. From the firewall itself I can SSH to VPN clients. And from one VPN to another I can SSH - though this flow isn't necessary it might be nice at some point. The problem is I can't SSH from hosts on 192.168.1.0/24 to VPN clients. Default policy for each chain, Input, Forward and Output is to drop.

I don't feel this is an OpenVPN problem but a netfilter (iptables) problem.

Relevant rules in place:

INPUT -p udp --dport 1194 -j ACCEPT
FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
FORWARD -i br0 -o tun0 -j ACCEPT
FORWARD -i tun0 -o br0 -j ACCEPT
FORWARD -s 192.168.254.0/24 -j ACCEPT
OUTPUT -d 192.168.254.0/24 -j ACCEPT

The above rules all get hits. I've tried other rules with various source and destination interfaces and IP addresses but can't come up with what is missing. The most obvious, I initially thought, was:

FORWARD -d 192.168.254.0/24 -j ACCEPT

...but when added it didn't work. Didn't even get hits.

=== EDIT 1 ===
The firewall has the following routes:

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 tun2

Also, the following rule (also listed above)...

FORWARD -i br0 -o tun0 -j ACCEPT

...gets hits when 192.168.1.0/24 hosts try to reach VPN clients.

=== EDIT 2 ===
From 192.168.1.x (.171 specifically) I did a traceroute --icmp 192.168.254.2 while running a packet capture on the firewall's tun0 interface and I see the the requests but no replies. The target, 192.168.254.2, replies to traceroute from 192.168.254.0/24. It allows all ICMP. This traffic is allowed by the broad firewall rule, FORWARD -i br0 -o tun0 -j ACCEPT and I see it logged accordingly.

Improve this question

2 Answers 2

Reset to default
0

Do you have this in your FORWARD table:

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Improve this answer
2
  • -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT. That is the same, yes? Or do I actually need to load conntrack? It's the first rule.
    – user1801810
    Jan 11, 2017 at 18:15
  • Ah yes, I see that conntrack is the "new state". So, yes, I have the necessary rule in place.
    – user1801810
    Jan 11, 2017 at 20:14
0

Either I am mistaken about how the local routing table works or something else is broken but here is what I did to get this working. I changed the local subnet of the VPN clients as it was the same as the subnet behind the VPN server, interface br0 on the VPN server.

The VPN server's firewall rules were correct and the VPN config was correct.

The routing tables on the VPN clients, when connected to VPN, were getting the correct routes with correct metric and interface... 0.0.0.0 and 192.168.1.0/24 with winning metric were both pointed to the tun0 interface.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .