OpenWrt Forum Archive

Topic: openvpn issue: tunnel is there but firewalled or whatsoever

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

i am facing the problem that after the connection is established, i can ping another VPN peer from my router (WRT54GS) but i can not ping another VPN peer (VPN 10.0.0.1)  from any of machines behind the router, as well as another VPN peer can not ping my router (VPN 10.0.0.2) where openvpn is running.
i disabled firewall for one second and then another VPN peer could ping my router but none of my internal machines could ping another VPN peer (10.0.0.1). pinging 10.0.0.2 is OK.

configuration:

another peer's openvpn.conf:

port 5678
proto udp
dev tun
secret key.txt
ifconfig 10.0.0.1 10.0.0.2
comp-lzo

my openvpn.conf:

remote xxx.no-ip.info 5678
dev tun
proto udp
ifconfig 10.0.0.2 10.0.0.1
secret key.txt
comp-lzo
route-up "route add -net 10.0.0.0 netmask 255.255.255.255 gw 10.0.1.2"

my internal network is 192.168.1.0/24 and all machines are DHCPd and having as default gateway internal network IP of WRT54GS (thus 10.0.0.2 pinging is OK).

another peer has no firewall - only port (udp 5678) forwarding to the server is configured on his router (not linksys).

i want to access from my internal machine only *one* port on the another VPN peer (10.0.0.1) and nothing more.

thank you very much in advance!

Did you enable FORWARDing?

KampfCaspar wrote:

Did you enable FORWARDing?

the forwarding itself is enabled:

~ # cat /proc/sys/net/ipv4/ip_forward
1

but there is no forwarding rule for if it is needed... i am a noob in iptables... i suppose such config (see above) is very common, can someone please give me a hint what to put in iptables...

Most probably, the forward definitions in iptable default to "deny". Have a look at firewall.user for examples how to insert rules.

KampfCaspar wrote:

Most probably, the forward definitions in iptable default to "deny". Have a look at firewall.user for examples how to insert rules.

you mean by "deny" - DROP?

i need just the exact 1-2-3 rules for my config (see above), then i just insert them in the beginning (not using "-APPEND" but using "-INSERT 1").
i do not understand why the tunnel is working at all between two peers. maybe i am wrong but i suppose that openvpn does not modify firewall settings, so the port 5678 of WAN interface on my router is closed. so how it is possible for the tunnel to work (i mean that openvpn establishes tunnel and i can ping another peer from the router).
i can post here "iptables --L" output to have a look. actually i do need only following rules:
1) forward to my ATA for SIP (udp 5060,16300-16500)
2) forward to my PC for edonkey (udp 4672)
3) openvpn usage with the config shown above (???)

then, i may try to create firewall settings from scratch - deny everything from WAN and only allow/forward (1-3). but how?!

thank you very much!

As I don't know neither your complete setup nor your current iptables rules, I cannot give you a "type in" solution.

Have a look at: http://iptables-tutorial.frozentux.net/ … orial.html

You'll find all answers (with examples) there.

KampfCaspar wrote:

As I don't know neither your complete setup nor your current iptables rules, I cannot give you a "type in" solution.

Have a look at: http://iptables-tutorial.frozentux.net/ … orial.html

You'll find all answers (with examples) there.

yes thank you for RTFM reference! my complete setup is above and i do need only these 1-2-3 additional rules! the place to put i'll find on my own!
can you tell me if i should use "-nat" options for masquerading? i do not need to know anything about internal network of another peer either he does not want to access mine. the deal is only between one internal machine in my network and his openvpn server... i suppose forwarding and postrouting rules should be used, as far as my machine behaves as client?
thank you!

No, I don't know your setup (this was the first time you mentioned masquerading, e.g.).

Yes, masquerading is defined in the "nat" table (-t nat) as it is a form of network address translation; as it is further a form of "source natting", it should be placed in the postrouting chain.

The FORWARD chain is not in the "nat" table, though. Depending on your default policy, you have to "-j ACCEPT" the packets you're willing to forward to the tun interface.

If you want to access "only" the 10./8 network, a simple network route should be fine. If you want to route ALL traffic through tun, don't forget to set a host route to the neighbouring vpn server.

i suppose i found at least one error in my openvpn's "route-up" routing rule:

route-up "route add -net 10.0.0.0 netmask 255.255.255.255 gw 10.0.1.2"

meanawhile 10.0.0.0/8 should be used for the route through 10.0.0.2 (in the route 10.0.1.2 stands as gw)

by the way, when i specify in openvpn.conf:

ifconfig 10.0.0.2 10.0.0.1

what netmask be used for this defined ip on tun interface?
thank you!

Unfortunately, I don't use openvpn... no idea about its configuration. The route-up command might only be needed on older kernels - those that did not set the route themselves.

KampfCaspar wrote:

Unfortunately, I don't use openvpn... no idea about its configuration. The route-up command might only be needed on older kernels - those that did not set the route themselves.

ok the solution of my problem is there (in case if somebody's interested):
1) after establishing connection with another VPN peer, see "ipconfig" output - "tun0" has 255.255.255.255 netmask
2) adopting "route-up" line in my openvpn.conf to:

route-up "route add -net 10.0.0.0 netmask 255.255.255.255 gw 10.0.1.2"

3) adding firewall rule

iptables -t nat -A POSTROUTING -o tun0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j SNAT --to-source 10.0.0.2

where xx:xx:xx:xx:xx:xx - MAC of my only client device. surely the configuration is very simple. and works only one-way (only i can establish connections and ping to another peer but him can not).
anyways thanks to anybody, solution found reading nice posts in this forum :-)

The discussion might have continued from here.