Problem setting up VPN client Rt-ac68u + PPPoE issues

[ColinTaylor]

Admittedly, I only checked AiCloud initially since that was immediately relevant to the OP. Again, the only time you need that rule is when the router-based service is bound *solely* to the LAN. I know that's the case for the GUI (httpd):

admin@merlin-lab1:/tmp/home/root# netstat -an | grep :8443
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.1:8443        0.0.0.0:*               LISTEN

Remote access is simply the result of a DNAT:

admin@merlin-lab1:/tmp/home/root# iptables -t nat -vnL VSERVER
Chain VSERVER (1 references)
pkts bytes target     prot opt in     out     source               destination
  180 10800 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 to:192.168.1.1:8443
    0     0 VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Yes, that was my point because the OP said he wanted both remote web access and AiCloud access.

I then checked FTP (port 21) for AiDisk:

admin@merlin-lab1:/tmp/home/root# netstat -an | grep :21
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN

Just as w/ AiCloud, the service is listening on all network interfaces, so you do NOT need that rule. If configured for LAN only (the default), there is no rule in the input chain for port 21 since all inbound access to the router is allowed by default. But if you enable WAN access, then a specific rule is added for that purpose.

admin@merlin-lab1:/tmp/home/root# iptables -vnL INPUT | grep :21
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:21

And that's why there's no need for a DNAT like there is for the GUI (httpd).

As I said, if you create a port forwarding rule to an internal FTP server as well as enabling AiDisk it changes to using a DNAT rule to the internal address. Therefore requiring the VPN rule. Admittedly that's an odd combination, but I did actually come across this situation when testing FTPS support with John.

Of course, you have to question why anyone would be enabling remote access to these services anyway (esp. ftp, which is in the clear, at least the GUI is using https).

To be fair I think RMerlin has disabled the ability to use plain FTP from the WAN, it has to be FTPS (at least that's the case in John's firmware).

But regarding whether it's necessary or not to have that VPN rule, in the case of the wiki documentation it's simpler to just include it rather than trying to explain the situations where it may be required. As you said, even if it's not required including it is benign.

 

[eibgrad]

As I said, if you create a port forwarding rule to an internal FTP server as well as enabling AiDisk it changes to using a DNAT rule to the internal address. Therefore requiring the VPN rule. Admittedly that's an odd combination, but I did actually come across this situation when testing FTPS support with John.

I assume by internal address, you mean the LAN ip of the router.

The use of DNAT has no bearing on this. All the DNAT does is change the destination IP, and thus the *incoming* network interface as seen by the service. But the *outgoing* network interface will still be that of the WAN (public IP), NOT the LAN, since the service is bound to all network interfaces.

IOW, the incoming network interface does NOT dictate the outgoing network interface. It's the source IP of those incoming packets that dictates it, and what network interfaces are available (and most suitable) to the service for the replies.

That's why the GUI requires the rule. It's because it's only bound to the LAN, NOT because of the DNAT. Just like the FTP server, binding the GUI to all network interfaces would eliminate the need for the rule, even if the DNAT remained and was the point of access.

To see for yourself, enable the FTP server, but only for the LAN (the default). Now apply the following firewall rules to allow DNAT'ing into that service over the WAN.

iptables -I INPUT -p tcp --dport 2121 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp --dport 2121 -j DNAT --to $(nvram get lan_ipaddr):21

What you'll find is access to the FTP server via port 2121 works just fine (provided you specify passive mode), even w/o the "192.168.1.1 WAN" routing policy rule.

But regarding whether it's necessary or not to have that VPN rule, in the case of the wiki documentation it's simpler to just include it rather than trying to explain the situations where it may be required. As you said, even if it's not required including it is benign.

I agree. To the extent it's benign, it's no harm, no foul.

My primary concern is for those trying to direct router *outbound* services to the VPN.

192.168.1.1 VPN

For most services, this is NOT going to produce the desired effect because most are bound to all network interfaces. So it's not quite so benign anymore. The problem w/ the wiki is that it leads you to believe you can control outbound router services, be it the WAN or VPN, by merely adding the router's IP to a rule. When configured for the WAN, it's mostly benign. But when configured for the VPN, it won't work as intended, and that can lead to frustration.

IOW, given the wiki, the following seems entirely plausible to most users.

192.168.1.100 VPN
192.168.1.1 VPN

But it ain't gonna do what the user thinks!

 

[ColinTaylor]

The use of DNAT has no bearing on this. All the DNAT does is change the destination IP, and thus the *incoming* network interface as seen by the service. But the *outgoing* network interface will still be that of the WAN (public IP), NOT the LAN, since the service is bound to all network interfaces.

IOW, the incoming network interface does NOT dictate the outgoing network interface. It's the source IP of those incoming packets that dictates it, and what network interfaces are available (and most suitable) to the service for the replies.

That's not quite correct. DNAT is relevant because we're not talking about establishing new outgoing connections from the ftp server. Were talking about replying via an established connection. The client creates a socket connection to the LAN IP/port (via DNAT). The response goes back through the same connection with conntrack "reversing" the DNAT. The response cannot go via a different interface because it would break the conntrack.

I cannot test this until tomorrow and it's quite likely you are correct and that WAN VPN rule is not needed. But I suspect that's more to do with the way conntrack interacts with RPDB rather than traffic coming in through one interface and going out of another.

N.B. I'm only thinking about the ftp control connection here and not the data connection, which is an entirely different ball game.

EDIT: OK I managed to test this and it doesn't work without the "192.168.1.1 WAN" rule. I tried this with and without the rule 3 times each. In all cases I can see the incoming connection being established. But without the WAN rule the replies are (presumably) ignored by the client because they appear to be coming from a different address (the VPN provider). In other words the end to end connection is broken because the traffic comes in via the WAN interface but returns via the VPN interface.

EDIT 2: Confirmed with tcpdump that the router is incorrectly replying through the VPN interface so the client never sends an ACK.

I have to say though, this is very much an edge case. It takes quite a lot of contrivance for it to be an issue. It's probably best ignored.

 

[ColinTaylor]

My primary concern is for those trying to direct router *outbound* services to the VPN.

192.168.1.1 VPN

For most services, this is NOT going to produce the desired effect because most are bound to all network interfaces. So it's not quite so benign anymore. The problem w/ the wiki is that it leads you to believe you can control outbound router services, be it the WAN or VPN, by merely adding the router's IP to a rule. When configured for the WAN, it's mostly benign. But when configured for the VPN, it won't work as intended, and that can lead to frustration.

IOW, given the wiki, the following seems entirely plausible to most users.

192.168.1.100 VPN
192.168.1.1 VPN

But it ain't gonna do what the user thinks!

That's a fair point.

 

[eibgrad]

That's not quite correct. DNAT is relevant because we're not talking about establishing new outgoing connections from the ftp server. Were talking about replying via an established connection. The client creates a socket connection to the LAN IP/port (via DNAT). The response goes back through the same connection with conntrack "reversing" the DNAT. The response cannot go via a different interface because it would break the conntrack.

I cannot test this until tomorrow and it's quite likely you are correct and that WAN VPN rule is not needed. But I suspect that's more to do with the way conntrack interacts with RPDB rather than traffic coming in through one interface and going out of another.

N.B. I'm only thinking about the ftp control connection here and not the data connection, which is an entirely different ball game.

EDIT: OK I managed to test this and it doesn't work without the "192.168.1.1 WAN" rule. I tried this with and without the rule 3 times each. In all cases I can see the incoming connection being established. But without the WAN rule the replies are (presumably) ignored by the client because they appear to be coming from a different address (the VPN provider). In other words the end to end connection is broken because the traffic comes in via the WAN interface but returns via the VPN interface.

EDIT 2: Confirmed with tcpdump that the router is incorrectly replying through the VPN interface so the client never sends an ACK.

I have to say though, this is very much an edge case. It takes quite a lot of contrivance for it to be an issue. It's probably best ignored.

What can I say, it works fine here. It's such an edge case, we might have slightly different configurations that could account for the differences. And is probably not worth pursuing.

 

[Nesalex]

WOW. I thought that I knew at least something about these things and based on what you were solving, I found out that I know almost nothing . The VPN service already works well for me, for which I am grateful, but I have one more problem that I would like to discuss. I don't want to put together a new thread, so I'll ask here.

About 2 weeks ago I ordered VDSL internet with a public IP address. Before my RT-AC68U I have a DSL router provider in BRIDGE mode. It happens that after restarting my router, router can't establish a connection and the router writes disconnected. Restarting the router will not help. I need to remove the VPN client configuration and the connection will be established after the restart. Disabling the service or disabling the automatic start of the VPN service will not help - the service settings must be completely cleared. I saw a thread here where people describe similar problems and also a comment from MERLIN where it says that VPN has nothing to do with WAN. But I don't think so - then why will deleting the VPN settings and the subsequent restart help? The worst part is that I can't help you find the problem because I'm just a beginner.

What would you suggest? Wait until the problem is resolved? I thought of uploading FW version 384.19 and test whether it works..

 

[eibgrad]

WOW. I thought that I knew at least something about these things and based on what you were solving, I found out that I know almost nothing . The VPN service already works well for me, for which I am grateful, but I have one more problem that I would like to discuss. I don't want to put together a new thread, so I'll ask here.

About 2 weeks ago I ordered VDSL internet with a public IP address. Before my RT-AC68U I have a DSL router provider in BRIDGE mode. It happens that after restarting my router, router can't establish a connection and the router writes disconnected. Restarting the router will not help. I need to remove the VPN client configuration and the connection will be established after the restart. Disabling the service or disabling the automatic start of the VPN service will not help - the service settings must be completely cleared. I saw a thread here where people describe similar problems and also a comment from MERLIN where it says that VPN has nothing to do with WAN. But I don't think so - then why will deleting the VPN settings and the subsequent restart help? The worst part is that I can't help you find the problem because I'm just a beginner.

What would you suggest? Wait until the problem is resolved? I thought of uploading FW version 384.19 and test whether it works..

Are you having problems establishing the connection between the WAN and the ISP, or is it working (e.g, you can ssh to the router and ping 8.8.8.8), but clients on the local network can't access it?

Because a common mistake it to configure the OpenVPN client and enable the kill switch ("Block routed clients if tunnel goes down"), then turn OFF the VPN. But what ppl sometimes don't realize is this still leaves the VPN's kill switch active! And unless you disable that option or clear the OpenVPN client completely, you won't have internet access by your clients.

 

[Nesalex]

Are you having problems establishing the connection between the WAN and the ISP

I think so because the router has no IP address and the home screen shows DISCONNECTED.

Thanks for the response. I don't know how to check or diagnose why my router doesn't have an active internet connection. I don't use an active kill switch in the VPN client - if the VPN connection is lost, I don't mind, I'll check the VPN functionality when I have enough time. In the WAN I have DNS servers set up not from my provider but 8.8.8.8 and 8.8.4.4 because I read here that it is recommended like this ...

 

[Nesalex]

I'm attaching a WAN configuration if needed.

 

[eibgrad]

On the face of it, Merlin is right. There is no obvious connection between your WAN connection issues and any OpenVPN client. What I find more likely to be the problem is your having recently changed your ISP provider. I realize you've drawn this correlation between the WAN and VPN, but of the two, the ISP seems more likely to be the issue. And diagnosing ISP connection issues is mighty difficult in the forum.

Have you considered placing the ISP modem back into router mode (at least temporarily), if only to see if it's capable of handling the ISP connection more reliably?

 

[Nesalex]

Zvažovali ste uvedenie modemu ISP späť do režimu smerovača (aspoň dočasne), len aby ste zistili, či je schopný spoľahlivejšie zvládnuť pripojenie ISP?

I'll consider it if it doesn't work with the original FW from Asus.

Ok I'll try the following:
1. I will upload the original FW for the router. If problems arise I will work with my ISP
2. If one week there is no problem I will upload FW merlin without VPN configuration and I will test ...

I will write what I found out !! THX

 

[Nesalex]

Hi. So I'm back. Three days ago I uploaded the latest official firmware 3.0.0.4.386_41634 to the router without making the factory settings. Everything works as it should except the system time error. After X restarts of the router, the connection via PPPoE was established. Each time the router gets a new IP address and the connection is active. Today I will activate the VPN client and I will continue to monitor it.

 

[Nesalex]

Can anyone look at this? At this time, the PPPoE connection dropped. THX


Mar 26 14:03:11 vpnclient5[1320]: TLS: tls_process: killed expiring key

Mar 26 14:03:12 vpnclient5[1320]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA

Mar 26 14:03:12 vpnclient5[1320]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA5

Mar 26 14:03:12 vpnclient5[1320]: VERIFY KU OK

Mar 26 14:03:12 vpnclient5[1320]: Validating certificate extended key usage

Mar 26 14:03:12 vpnclient5[1320]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

Mar 26 14:03:12 vpnclient5[1320]: VERIFY EKU OK

Mar 26 14:03:12 vpnclient5[1320]: VERIFY OK: depth=0, CN=sk34.nordvpn.com

Mar 26 14:03:14 vpnclient5[1320]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mar 26 14:03:14 vpnclient5[1320]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mar 26 14:03:14 vpnclient5[1320]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA

Mar 26 14:06:22 syslog: wlceventd_proc_event(507): eth1: Disassoc D8:9B:3B:F6:CC:E4, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

Mar 26 14:06:24 syslog: wlceventd_proc_event(526): eth1: Auth D8:9B:3B:F6:CC:E4, status: Successful (0), rssi:0

Mar 26 14:06:24 syslog: wlceventd_proc_event(555): eth1: Assoc D8:9B:3B:F6:CC:E4, status: Successful (0), rssi:0

Mar 26 14:06:24 dnsmasq-dhcp[678]: DHCPDISCOVER(br0) d8:9b:3b:f6:cc:e4

Mar 26 14:06:24 dnsmasq-dhcp[678]: DHCPOFFER(br0) 192.168.1.48 d8:9b:3b:f6:cc:e4

Mar 26 14:06:24 dnsmasq-dhcp[678]: DHCPREQUEST(br0) 192.168.1.48 d8:9b:3b:f6:cc:e4

Mar 26 14:06:24 dnsmasq-dhcp[678]: DHCPACK(br0) 192.168.1.48 d8:9b:3b:f6:cc:e4 HUAWEI_Mate_20_Pro-236209

Mar 26 14:06:49 kernel: nvram: consolidating space!

Mar 26 14:06:56 syslog: wlceventd_proc_event(507): eth1: Disassoc BCD:C2:E3:75:C9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Mar 26 14:06:58 syslog: wlceventd_proc_event(526): eth1: Auth BCD:C2:E3:75:C9, status: Successful (0), rssi:0

Mar 26 14:06:58 syslog: wlceventd_proc_event(555): eth1: Assoc BCD:C2:E3:75:C9, status: Successful (0), rssi:0

Mar 26 14:07:00 dnsmasq-dhcp[678]: DHCPDISCOVER(br0) bc:dd:c2:e3:75:c9

Mar 26 14:07:00 dnsmasq-dhcp[678]: DHCPOFFER(br0) 192.168.1.152 bc:dd:c2:e3:75:c9

Mar 26 14:07:00 dnsmasq-dhcp[678]: DHCPREQUEST(br0) 192.168.1.152 bc:dd:c2:e3:75:c9

Mar 26 14:07:00 dnsmasq-dhcp[678]: DHCPACK(br0) 192.168.1.152 bc:dd:c2:e3:75:c9 ESP_E375C9

Mar 26 14:07:00 kernel: BCD:C2:E3:75:C9 not mesh client, can't update it's ip

Mar 26 14:07:55 syslog: wlceventd_proc_event(507): eth1: Disassoc BCD:C2:E3:75:C9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Mar 26 14:07:57 syslog: wlceventd_proc_event(526): eth1: Auth BCD:C2:E3:75:C9, status: Successful (0), rssi:0

Mar 26 14:07:57 syslog: wlceventd_proc_event(555): eth1: Assoc BCD:C2:E3:75:C9, status: Successful (0), rssi:0

Mar 26 14:07:59 dnsmasq-dhcp[678]: DHCPDISCOVER(br0) bc:dd:c2:e3:75:c9

Mar 26 14:07:59 dnsmasq-dhcp[678]: DHCPOFFER(br0) 192.168.1.152 bc:dd:c2:e3:75:c9

Mar 26 14:07:59 dnsmasq-dhcp[678]: DHCPREQUEST(br0) 192.168.1.152 bc:dd:c2:e3:75:c9

Mar 26 14:07:59 dnsmasq-dhcp[678]: DHCPACK(br0) 192.168.1.152 bc:dd:c2:e3:75:c9 ESP_E375C9

Mar 26 14:07:59 kernel: BCD:C2:E3:75:C9 not mesh client, can't update it's ip

 

[ColinTaylor]

Can anyone look at this? At this time, the PPPoE connection dropped. THX

I can't see anything there that indicates a problem with PPPoE.

 

[Nesalex]

I can't see anything there that indicates a problem with PPPoE.

At that time, the connection was lost. Photo 1 shows the status when the page is updated, and Photo 2 shows the status 0.5 seconds later. For a short time, the IP starts up there and after 0.5 seconds it writes disconnected. I will try to upload 384.19 ..

 

[ColinTaylor]

It's likely that the PPPoE connection wasn't actually disconnected at all. There are numerous posts in these forums reporting a "false" disconnected status.

 

[Nesalex]

It's likely that the PPPoE connection wasn't actually disconnected at all. There are numerous posts in these forums reporting a "false" disconnected status.

It's possible that the real connection won't end, but why does the router think so? The truth is that devices connected to the router do not have access to the Internet ....

 

[Nesalex]

So I'm back. I've been on version 384.19 for 6 days now and everything works. No loss of connection via PPPoE. A few restarts and still OK. The connection is still established.
I tried:
RT-AC68U_386.2_beta3.zip 2021-03-28 NOK
RT-AC68U_386.2_beta2.zip 2021-03-20 NOK
RT-AC68U_386.2_beta1.zip 2021-03-10 NOK
RT-AC68U_386.1_2.zip 2021-02-12 NOK
RT-AC68U_386.1_beta5.zip 2021-01-26 NOK
Official Version 3.0.0.4.386.41634 2021/01/18 NOK
RT-AC68U_386.1_beta4.zip 2021-01-09 NOK

RT-AC68U_384.19_0.zip 2020-08-14 Works perfectly

I still found one option that I haven't tried in previous versions, and that is to turn off NAT acceleration. Maybe I'll try it sometime ..

 

[Nesalex]

Hi. I didn't have time to experiment with the router and I'm not an expert in the subject. Once I came up with a way to solve my problem, I didn't dig into it anymore. Gradually, I did a downgrade of the FW to version 384.19_0, where everything worked without problems for me, and then I only did a dirty update of the FW. Everything is OK. I'm working on 386.3_2 but I can't do a factory reset because the problem will come back (at least I think because it was after 386.2_6) and I don't want to risk the problem right now. Interestingly, when I solved the problem, I also used the latest official version of FW (ASUS) and I also had a problem with disconnecting the WAN ...

 

[eibgrad]

Hi. I didn't have time to experiment with the router and I'm not an expert in the subject. Once I came up with a way to solve my problem, I didn't dig into it anymore. Gradually, I did a downgrade of the FW to version 384.19_0, where everything worked without problems for me, and then I only did a dirty update of the FW. Everything is OK. I'm working on 386.3_2 but I can't do a factory reset because the problem will come back (at least I think because it was after 386.2_6) and I don't want to risk the problem right now. Interestingly, when I solved the problem, I also used the latest official version of FW (ASUS) and I also had a problem with disconnecting the WAN ...

Sounds to me like you have a tiger by tail w/ that solution. Dirty upgrades can lead to all kinds of problem in and of themselves. Esp. when you make that big a leap. New features like the VPN Director are likely to have issues given its a major change in how routing policy is handled, w/ significant changes to nvram variables, code execution, etc.

So while it's nice that things are working the way you want, I can't help but wonder how long the party is going to last before you discover other issues.

Anyway, if it's working for you, great!