Topic: openvpn server mode almost works...

The content of this topic has been archived on 28 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

compi

9 Jun 2007, 00:03

Hi,

I'm trying to implement an openvpn server on my wrt54g, and i'm really almost there

I copied all the keys, and config files from my previously working debian based firewall pc, and the openvpn channel seems to work fine.

LAN is the usual 192.168.1.0/24 and i selected 192.168.31.0/24 for openvpn addresses. The connection builds up fine from the client and i can see the router on both 192.168.1.1 and 192.168.31.1 but that's all. Pinging machines on the LAN does not work, however if I'm receiving Destination Host Unreachable from 192.168.31.1 (the router's tun0 interface address)

Here is my server.conf:

port 1194
proto udp

dev tun

ca ca.crt
cert compi.dyndns.org.crt
key compi.dyndns.org.key  # This file should be kept secret
dh dh1024.pem

server 192.168.31.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.1.0 255.255.255.0"

client-to-client

keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

my firewall.user:

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

# The following chains are for traffic directed at the IP of the
# WAN interface

iptables -F input_wan
iptables -F forwarding_wan
iptables -t nat -F prerouting_wan

### Open port to WAN
## -- This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

### OpenVPN
## allow connections from outside
iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables        -A input_wan      -p udp --dport 1194 -j ACCEPT

iptables -A INPUT   -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT   -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

### Port forwarding
## -- This forwards port 8080 on the WAN to port 80 on 192.168.1.2
# iptables -t nat -A prerouting_wan -p tcp --dport 8080 -j DNAT --to 192.168.1.2:80
# iptables        -A forwarding_wan -p tcp --dport 80 -d 192.168.1.2 -j ACCEPT

### DMZ
## -- Connections to ports not handled above will be forwarded to 192.168.1.2
iptables -t nat -A prerouting_wan -j DNAT --to 192.168.1.2
iptables        -A forwarding_wan -d 192.168.1.2 -j ACCEPT

And on the end here are the iptables rules as dumped by iptables-save:

# Generated by iptables-save v1.3.3 on Fri Jun  8 23:00:07 2007
*nat
:NEW - [0:0]
:PREROUTING ACCEPT [80:6750]
:POSTROUTING ACCEPT [5:1714]
:OUTPUT ACCEPT [7:1429]
:postrouting_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan - [0:0]
-A NEW -m limit --limit 50/sec --limit-burst 100 -j RETURN 
-A NEW -j DROP 
-A PREROUTING -m state --state NEW -j NEW 
-A PREROUTING -j prerouting_rule 
-A PREROUTING -i vlan1 -j prerouting_wan 
-A POSTROUTING -j postrouting_rule 
-A POSTROUTING -o vlan1 -j MASQUERADE 
-A prerouting_wan -p tcp -m tcp --dport 22 -j ACCEPT 
-A prerouting_wan -p udp -m udp --dport 1194 -j ACCEPT 
-A prerouting_wan -j DNAT --to-destination 192.168.1.2 
COMMIT
# Completed on Fri Jun  8 23:00:07 2007
# Generated by iptables-save v1.3.3 on Fri Jun  8 23:00:07 2007
*mangle
:PREROUTING ACCEPT [1053:151837]
:INPUT ACCEPT [784:82831]
:FORWARD ACCEPT [211:59588]
:OUTPUT ACCEPT [668:111316]
:POSTROUTING ACCEPT [883:175957]
COMMIT
# Completed on Fri Jun  8 23:00:07 2007
# Generated by iptables-save v1.3.3 on Fri Jun  8 23:00:07 2007
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:LAN_ACCEPT - [0:0]
:OUTPUT DROP [0:0]
:forwarding_rule - [0:0]
:forwarding_wan - [0:0]
:input_rule - [0:0]
:input_wan - [0:0]
:output_rule - [0:0]
-A INPUT -m state --state INVALID -j DROP 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp ! --tcp-option 2 --tcp-flags SYN SYN -j DROP 
-A INPUT -j input_rule 
-A INPUT -i vlan1 -j input_wan 
-A INPUT -j LAN_ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -p gre -j ACCEPT 
-A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -i tun+ -j ACCEPT 
-A INPUT -i tap+ -j ACCEPT 
-A FORWARD -m state --state INVALID -j DROP 
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -j forwarding_rule 
-A FORWARD -i vlan1 -j forwarding_wan 
-A FORWARD -i br0 -o br0 -j ACCEPT 
-A FORWARD -i br0 -o vlan1 -j ACCEPT 
-A FORWARD -i tun+ -j ACCEPT 
-A FORWARD -i tap+ -j ACCEPT 
-A LAN_ACCEPT -i vlan1 -j RETURN 
-A LAN_ACCEPT -j ACCEPT 
-A OUTPUT -m state --state INVALID -j DROP 
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -j output_rule 
-A OUTPUT -j ACCEPT 
-A OUTPUT -p tcp -j REJECT --reject-with tcp-reset 
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable 
-A forwarding_wan -d 192.168.1.2 -j ACCEPT 
-A input_wan -p tcp -m tcp --dport 22 -j ACCEPT 
-A input_wan -p udp -m udp --dport 1194 -j ACCEPT 
COMMIT
# Completed on Fri Jun  8 23:00:07 2007

the whole setup is based on http://wiki.openwrt.org/OpenVPNTunHowTo … 01d5668d58

I'm quite sure that the problem should be somewhere in the iptables rules, but i cannot find myself what did I do wrong.

Thanks in advance,

compi

Post #2

Bill_MI

9 Jun 2007, 04:08

Hi Compi,

There's a lot of ways to set up networks but I'm reading between the lines that you want OpenVPN clients to access your LAN from the outside world coming in to the WRT54G WAN address... correct?

If so, you need to run *bridging* mode. The Wiki page you referenced has a link about bridging that may help. It says little about the fact it connects to the router but nowhere else - which is what you're getting. I think this may help...

In bridging mode the 'server' line becomes a 'server-bridge' line with most parameters - but clients get assigned regular LAN addresses (no need for 10.* or your 192.168.31 addresses). These are all on this server-bridge line.

The tap0 interface is typically created, bridged to the LAN and enabled in startup scripts.

I have a configuration I've been using for over a year now that works in the fashion I describe:
http://forum.openwrt.org/viewtopic.php?id=9609

Hope this helps

Post #3

compi

9 Jun 2007, 08:26

Hi Bill,

Bill_MI wrote:

There's a lot of ways to set up networks but I'm reading between the lines that you want OpenVPN clients to access your LAN from the outside world coming in to the WRT54G WAN address... correct?

That's the first part of the business. The second part is probably even more important: I want to be able to access the client (e.g my workstation at my workplace) from home. According the topology you're right, there is a subnet of 192.168.1.0/24 on the LAN i want to access, and y want to access the clients from.

Bil_MI wrote:

If so, you need to run *bridging* mode. The Wiki page you referenced has a link about bridging that may help.

Bridging mode is surely one option, but in my case it is only an emergency route. I had a working routed mode setup on my previous debian based firewall and I'd like to implement the same at first place, as I understand routing a lot better than bridging.

Bill_MI wrote:

It says little about the fact it connects to the router but nowhere else - which is what you're getting. I think this may help...

In the example config file on the wiki you can find:

### (optional) make local network behind the VPN server accessible for the VPN clients
push "route 192.168.1.0 255.255.255.0"

And there is also a paragraph about troubleshooting if the network behind the LAN not accessible from clients. And i had the same topology on my previous PC based firewall, so it should work I suppose. I suppose the routing is right : wrt54g leg of the vpn responds Destination Host Unreachable if i try to reach an IP with no computer behind it on the LAN, and this message stops as soon as I switch that PC on. I also verified the routing tables on both sides and they're fine, ip_forward is 1. Only one step remained which is a little bit over-complicated in WhiteRussian IMHO: iptables.

Bil_MI wrote:

In bridging mode the 'server' line becomes a 'server-bridge' line with most parameters - but clients get assigned regular LAN addresses (no need for 10.* or your 192.168.31 addresses). These are all on this server-bridge line.
The tap0 interface is typically created, bridged to the LAN and enabled in startup scripts.
I have a configuration I've been using for over a year now that works in the fashion I describe:
http://forum.openwrt.org/viewtopic.php?id=9609
Hope this helps

Thanks, if the routed mode fails I'll go that way, but I cannot simply give it up without finding the reason.

Post #4

Bill_MI

9 Jun 2007, 13:56

Understood, Compi. This is far more tap/tun routing rules exercise which I've avoided entirely with the simplicity of bridging.

Post #5

compi

10 Jun 2007, 00:23

just for those will have the same problem in the future:

Rules suggested to be inserted into firewall.user are far not enough. The wiki suggests these:

iptables -A INPUT   -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT   -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

First of all, tap devices are used in bridged mode, routed mode uses only tun, hence tap rules are needless. Tun rules are incomplete. The correct rules are:

iptables -A INPUT   -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT
iptables -A OUTPUT  -o tun+ -j ACCEPT

After adding the two missing rule to my firewall.user, my routed mode vpn works flawlessly.

Thanks for the support and would someone correct the wiki please?

Post #6

maddes.b

2 Aug 2007, 15:02

Hello compi,

I'm one of the contributors of the TUN wiki page. The iptables definitions were taken from the original OpenVPN page.

Today I also experienced this problem (finally really using the VPN).
My assumption was that outgoing rules are missing and searched the forum.
So thanks for finding and testing the additional iptables definition.

Btw you're welcome to contribute to the wiki pages and correct this stuff yourself.
Everybody is allowed to register for the wiki and then edit or create new pages.
I will update the wiki page with your data.

Kind regards
Maddes

(Last edited by maddes.b on 2 Aug 2007, 15:06)

The discussion might have continued from here.

Page 1 of 1