Beginner VPN questions with FreshTomato

[Jherb]

Hello,
I hope this is an appropriate question for this forum. I am a beginner with VPNs, and need some guidance.
I am using an ac68u with freshtomato firmware.

I am struggling to get the vpn to work.
I followed the instructions I found on the web at https://learntomato.flashrouters.com/how-to-setup-a-vpn-server-with-tomato-openvpn/
The latest version of freshtomato allows you to generate the static key from the gui. So i did that, and exported the client file.
Then imported the client file in openVPNgui on a windows 10 machine.

When I try to connect, I get the below and it just stays there forever. I really don't know whats going on so any help or reference to a guide would be very helpful.

My settings are in the screenshots below, as well as the lines from the log which is verbatim except the remote IP address numbers are changed to *.


Appreciate any guidance.

Sat Oct 30 19:50:57 2021 TAP-Windows Driver Version 9.24
Sat Oct 30 19:50:57 2021 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.6.0.2/255.255.255.252 on interface {B6039859-AC23-4C3A-9B29-3E80685D43FD} [DHCP-serv: 10.6.0.1, lease-time: 31536000]
Sat Oct 30 19:50:57 2021 Successful ARP Flush on interface [19] {B6039859-AC23-4C3A-9B29-3E80685D43FD}
Sat Oct 30 19:50:57 2021 MANAGEMENT: >STATE:1635637857,ASSIGN_IP,,10.6.0.2,,,,
Sat Oct 30 19:50:57 2021 IPv4 MTU set to 1500 on interface 19 using service
Sat Oct 30 19:50:57 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Sat Oct 30 19:50:57 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Oct 30 19:50:57 2021 UDP link local: (not bound)
Sat Oct 30 19:50:57 2021 UDP link remote: [AF_INET]*.*.*.*:1194

 

[eibgrad]

Lots of possibilities here.

Do you have a public IP on the WAN? Remote access *requires* a public IP, and many ppl are behind private networks, esp. CGNAT.

Sometimes ISPs block the well-known ports. Even if that isn't the case, it's a bad idea to use them because hackers and bots will be hammering those ports the minute they find they're active. Better to use something more obscure, 10000 and above (e.g., 19455).

Rather unusual to use a static key rather than TLS. Yeah, you can do it, but realize a) you can only have *one* client for that server at a time, b) and the static key grows stale over time. And by using the defaults for the cipher and auth, you're not doing yourself any favors. They will work, but they're also the weakest choices. In fact, it's possible some OpenVPN clients *might* refuse to accept them.

What's the OpenVPN server syslog show? Minimally you want some indication the client is at least reaching the server, then if there's an error or other issue, you can address it. But if the client *and* server are just sitting there, that suggests the problem lies w/ remote access itself, as I suggested initially.

 

[Jherb]

Thank you for your response. Very helpful questions, and I'll share the minimal that I know.

the router stats show the below, so it seems like something is getting through.

Name	Value
TUN/TAP read bytes	0
TUN/TAP write bytes	28425
TCP/UDP read bytes	35380
TCP/UDP write bytes	240
Auth read bytes	29162

Regarding the static key, I tried the TLS settings but I couldn't get it to work, so tried to make it simpler until I learn what is going on.

If you have a guide or some help regarding how to do the TLS stuff with each setting that needs to be modified, I'd be happy to try it.

One thing I didn't understand was this question? Do you have a public IP on the WAN? Remote access *requires* a public IP, and many ppl are behind private networks, esp. CGNAT.

--Do I need to do something special to get a public IP? When I set up the VPN on another router with Merlin firmware, it was much easier and worked right away. I'm newer to tomato, so I'm not sure if I need to do something here. I thought that the tomato "create keys" stuff already took care of identifying the public IP etc.
Just for background, the router is attached to a cable modem in a regular home. I don't know how to check if I have a public IP address.

--As a test, would it be possible to connect to the VPN from within the local network just to make sure they are communicating? I tried , but got the same issue where it doesn't get past the log line I shared in the previous post.

Sorry for my ignorance, I'm trying to learn as I go along. I appreciate your help.

 

[eibgrad]

Thank you for your response. Very helpful questions, and I'll share the minimal that I know.

the router stats show the below, so it seems like something is getting through.

Name	Value
TUN/TAP read bytes	0
TUN/TAP write bytes	28425
TCP/UDP read bytes	35380
TCP/UDP write bytes	240
Auth read bytes	29162

True. But it's not always easy to interpret what that table means. Notice nothing is being read. I still want to see the server syslog. That usually tells you if the client has at least reached the server.

You could also use ssh/telnet (or even Tools->System Commands) and dump the INPUT chain on the filter table of the firewall to see if the inbound port for the server (1194) is getting any hits. If it isn't, that's another indication you might not have a public IP.

iptables -vnL INPUT

Regarding the static key, I tried the TLS settings but I couldn't get it to work, so tried to make it simpler until I learn what is going on.

FT does have a known bug w/ generating keys and certs. That may have been what you encountered. I believe the fix is coming w/ the next release (or perhaps is already in 2021.7)

OpenVPN generated files: error=invalid CA certificate

OpenVPN server: ASUS RT-AC68U running FreshTomato 2021.5 OpenVPN client: ASUS RT-10P running FreshTomato 2021.5 I'm having a problem using the generated keys and certs (the CA cert specifically) of the OpenVPN server. My first encounter w/ this problem came while helping someone on DSL Reports...

www.linksysinfo.org

If you have a guide or some help regarding how to do the TLS stuff with each setting that needs to be modified, I'd be happy to try it.

There is the FT wiki (not sure how good it is, I just know it's there).

openvpn_server [FreshTomato Wiki]

wiki.freshtomato.org

One thing I didn't understand was this question? Do you have a public IP on the WAN? Remote access *requires* a public IP, and many ppl are behind private networks, esp. CGNAT.

--Do I need to do something special to get a public IP? When I set up the VPN on another router with Merlin firmware, it was much easier and worked right away. I'm newer to tomato, so I'm not sure if I need to do something here. I thought that the tomato "create keys" stuff already took care of identifying the public IP etc.
Just for background, the router is attached to a cable modem in a regular home. I don't know how to check if I have a public IP address.

Every router requires a public IP for remote access purposes. If you go to a website like ipchicken.com, it will tell your current public IP. That *must* match the WAN ip on your FT router (see the Overview page). If it doesn't, that means your router is probably on a *private* network and is remotely unreachable. That could be because your router isn't the primary router, but perhaps daisy-chained by the ISP's modem+router (WAN to LAN respectively), in which case, you have options. OTOH, if your router *is* the primary router and you see a private IP, it means your behind the ISP's router *upstream* of your modem, leaving little if any options (other than to complain to the ISP). In the latter case, it's usually CGNAT (a specific portion of the private IP space reserved for ISPs; they usually begin w/ 100.64.x.x).

--As a test, would it be possible to connect to the VPN from within the local network just to make sure they are communicating? I tried , but got the same issue where it doesn't get past the log line I shared in the previous post.

I don't generally recommend that type of internal testing, esp. w/ a VPN. A VPN is unlike other services made available over the WAN. It changes the routing tables, which can sometimes lead to misleading results. It does NOTHING to prove that you have remote access. Even if you got connected locally, it wouldn't be unexpected since the router generated (and presumably you imported) the matching client config file.

 

[Jherb]

Thanks again.
So I checked with ipchicken and the IP value is the same as the WAN IP value in the overview page.

I changed my settings to try to use tls, they are below. What I see now in the client list is below. The syslog is there too but I don't understand it, so hopefully you will.

Oct 30 23:36:17 unknown daemon.warn openvpn-server1[28625]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28625]: OpenVPN 2.5.4 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28625]: library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Diffie-Hellman initialized with 1024 bit key
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: TUN/TAP device tun21 opened
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: TUN/TAP TX queue length set to 1000
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: /usr/sbin/ip link set dev tun21 up mtu 1500
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: /usr/sbin/ip link set dev tun21 up
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: /usr/sbin/ip addr add dev tun21 10.6.0.1/24
Oct 30 23:36:17 unknown daemon.warn openvpn-server1[28626]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: setsockopt(IPV6_V6ONLY=0)
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: UDPv6 link local (bound): [AF_INET6][undef]:19456
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: UDPv6 link remote: [AF_UNSPEC]
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: MULTI: multi_init called, r=256 v=256
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: IFCONFIG POOL IPv4: base=10.6.0.2 size=252
Oct 30 23:36:17 unknown daemon.notice openvpn-server1[28626]: Initialization Sequence Completed
Oct 30 23:36:37 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:36:37 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:36:37 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:36:37 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:36:37 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 TLS: Initial packet from [AF_INET6]::ffff:10.0.0.31:56041, sid=bd815235 cd664bc2
Oct 30 23:37:16 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56044 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:37:16 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56044 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:37:16 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56044 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 30 23:37:16 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56044 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 30 23:37:16 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56044 TLS: Initial packet from [AF_INET6]::ffff:10.0.0.31:56044, sid=813281f0 cd023e71
Oct 30 23:37:38 unknown daemon.err openvpn-server1[28626]: 10.0.0.31:56041 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 30 23:37:38 unknown daemon.err openvpn-server1[28626]: 10.0.0.31:56041 TLS Error: TLS handshake failed
Oct 30 23:37:38 unknown daemon.notice openvpn-server1[28626]: 10.0.0.31:56041 SIGUSR1[soft,tls-error] received, client-instance restarting

 

[eibgrad]

Did you regenerate a new OpenVPN client configuration file and use it?

If problems persist, try disabling the TLS auth option (it's only for the purpose of DOS/DDOS protection anyway, which is NOT a big concern for home users). It just represents one more obstacle. Also, that option might not be available w/ all OpenVPN clients (it was a feature added in only the last few releases of OpenVPN).

P.S. And remember, after most changes to the server config, you need to regenerate and use the client config file.

 

[Jherb]

Hello.
Yes, I did regenerate the client config file. After every round of changes, but so far no luck. I disabled the tls auth, with no difference.

I'm going to keep playing around, but did you notice anything in the syslog that helps? I noticed TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity), but I'm not sure if that means the client wasn't reaching the external IP address like you mentioned, or something else.

 

[Jherb]

This is the syslog after I set it up again. Still the same issue.
My setup is simple so I'm not sure why its giving me issues. I don't have an ISP modem, I have a dedicated modem not a combo device. My router is connected to it.

The syslog is attached.

A couple of naive questions from what I read on the web.
I read in one example of ports needing to be forwarded. Is that the case here?
In the merlin firmware, there was an option for username/password. How do you do that in tomato?

Thanks again

 

[eibgrad]

Unless your router is configured for IPv6, please select UDP4 in the protocol field of the OpenVPN server GUI.

That will probably NOT fix anything, but it will prevent it from unnecessarily binding to IPv6. As always, regenerate the client config file.

Port forwarding is NOT needed for two reasons. First, the router is hosting both the internet connection (via its WAN) and the OpenVPN server, so there's nothing to be forward to (iow, it's not as if you're trying to reach (forward) a request from the router to some other LAN device). Second, the router automatically opens the necessary port on its WAN, based on your specified port and protocol (udp or tcp) in the GUI, and as soon as the OpenVPN server is started.

What the log shows is (apparently) an attempt to connect from a client within the same local IP network as the server.

Oct 31 04:17:07 unknown daemon.notice openvpn-server1[11574]: 10.0.0.31:60715 TLS: Initial packet from [AF_INET6]::ffff:10.0.0.31:60715, sid=cf322b76 c8d08699

At least that's all I can assume given the client's IP is private (10.0.0.31). As I said, that proves nothing. You need to access the server from the internet side of your WAN (I typically use a smartphone for such testing).

 

[Jherb]

Unless your router is configured for IPv6, please select UDP4 in the protocol field of the OpenVPN server GUI.

That will probably NOT fix anything, but it will prevent it from unnecessarily binding to IPv6. As always, regenerate the client config file.

Port forwarding is NOT needed for two reasons. First, the router is hosting both the internet connection (via its WAN) and the OpenVPN server, so there's nothing to be forward to (iow, it's not as if you're trying to reach (forward) a request from the router to some other LAN device). Second, the router automatically opens the necessary port on its WAN, based on your specified port and protocol (udp or tcp) in the GUI, and as soon as the OpenVPN server is started.

What the log shows is (apparently) an attempt to connect from a client within the same local IP network as the server.

Oct 31 04:17:07 unknown daemon.notice openvpn-server1[11574]: 10.0.0.31:60715 TLS: Initial packet from [AF_INET6]::ffff:10.0.0.31:60715, sid=cf322b76 c8d08699

At least that's all I can assume given the client's IP is private (10.0.0.31). As I said, that proves nothing. You need to access the server from the internet side of your WAN (I typically use a smartphone for such testing).

Thanks a lot for your help. I've been trying from the LAN and outside, but I've had no luck. I'll keep trying and reset the router in case something is messed up. The cell phone is a good suggestion. I've been using my mobile hotspot to test.