No, I'm not behind cgnat.
I've made a mistake before when you asked me: and does it match the one on the WAN port ?. The answer is yes, the WAN ip is the same as whatismyip.com
well, of course, you're not going via internet when you do.
you should probably remove the src_dport, or set it to any/empty.
if your router's the 192.168.1.1, you shouldn't really need the redirect, just open the 1194 port in the firewall.
I've already did this, and no solution.
I think the problem is something related with security and not firewall, but I can't figure it out.
Thanks to everyone
check if your ISP actually allows incoming traffic from internet to your public IP.
It allows. I've made the same mounting a vpn server on a RPi4 and it works flawlessly.
The thing with OVPN is that the server only looks at the WAN port you specify.
Then you need to open that port in the firewall.
But you can’t route it to the LAN in this way you have done. The data on the “inside” (LAN) of the server go in and out of the OVPN server with a tun or tap network connection as a device to the firewall zone you wish to use. For tap network you can in some cases use VLAN also.
OVPN doesn’t work for “internal use” unless you reroute the data to wan side first. That is why I asked if you actually have a working encrypted connection according to the openvpn log or if you only are connected as usual to the network/wifi.
OVPN can run tunnels without encryption also!
Thanks for the help.
I've found the problem. UDP port is not opening via firewall. If I listen on 1194 TCP port, I can connect from lan/internet to openvpn server without problem, but if I set openvpn server to listen on udp port, I can't open it. So the problem is opening udp in the firewall.
Any advice ?
Have you told the client to use udp?
What firewall setup do you have right now?
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
Just curious, have you read the manual or are you just going for the trial and error tactic when setting up your own OpenVPN tunnel?
Yes. Clients are using udp.
This is my firewall config working on tcp but not on udp:
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option synflood_protect '1'
option forward 'REJECT'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list device 'tun0'
list device 'tun+'
config zone 'wan'
option name 'wan'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
list network 'wan'
option forward 'REJECT'
option input 'REJECT'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled '0'
config rule 'ovpn'
option name 'Allow-OpenVPN'
option src 'wan'
option target 'ACCEPT'
list proto 'tcp'
list proto 'udp'
list dest_ip '192.168.1.1'
option dest_port '1194'
config include
option path '/etc/firewall.user'
config redirect
option target 'DNAT'
option src 'wan'
list proto 'tcp'
list proto 'udp'
option dest 'lan'
option src_dport '1194'
option dest_port '1194'
option name 'ovpn'
option dest_ip '192.168.1.1'
Right now I'm in the trial/error part. In the beginning, obviously I had to read to understand.
Tunnel is working on tcp, so I think this is not the problem. It's something related to firewall that I can't discover.
Setting dest_ip to a non-public IP is wrong. To open a port you only need options src, target, proto, and dest_port. Firewall rules act only if all the specified conditions match. So don't impose extra conditions.
The old syntax was option proto 'tcp udp' I don't know if multiple protocols can be done with list proto. But two points on that, if you're running the server in UDP mode you don't need to allow TCP at all, and if you wanted to allow both you could write two separate rules.
Also, your ISP may be blocking UDP or not forwarding it correctly. In that case the workaround is to use TCP.
My isp has nothing to do with the problem because I've tested everything using a RPi4 and it works.
I'gonna try separating rules in different lines and deleting dest_ip.
Not working. Very odd problem.
I've changed the router to test with the isp's and no problem, I can connect via udp protocol, so that concludes that the problem is in openwrt firewall.
Thanks again for the help. I'll keep investigating.
I thought you were running OpenVPN on your main router, in that case you would open the port to allow incoming connections on the local router. If you have a separate server you need to configure the main router to forward the public VPN server port to it.
Scrolling down to the bottom of your configuration (which I assume is the main router) you have done both, which is not going to work. The first rule listed that matches the conditions will take action and subsequent rules will be ignored. So since the local open is listed first the packet is accepted and sent to the OpenWrt OS, where it is then refused since there is no process bound to the port.
1 Like
Rules in the nat table take priority over the filter table.
Anyway, the current topology is too confusing for me to comment.
1 Like
Yes, oVPN is running in the main router and the port allows incoming connections to de router. I did this, several times.
I don't understand when u say: since there is no process bound to the port., of course there is a process bounded to the port and is oVPN server:`
root@OpenWrt:~# netstat -lp | grep openvpn
udp 0 0 0.0.0.0:openvpn 0.0.0.0:* 16788/openvpn
Odd odd issue. I'm starting to think it's a bug.
Working now.
For anyone who needs help, I must say that I don't know what was the problem.
I reinstalled everything from zero and now it works, but some advice is that in the firewall zones, tun0 must be specified in the covered devices. If everything fails, start from scratch cleaning every config file. When you're stuck, you change things here and there and lost control of this changes. This is what I did.
Thanks to everybody who helped me.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.