Problem setting up VPN client Rt-ac68u + PPPoE issues

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Nesalex

Occasional Visitor
Hi. I have a problem with setting up my VPN connection. I used this procedure to configure:


This procedure is for another router but I thought it might work .. I have an Asus RT-AC68U router and FW version 386.1_2

When I downloaded the configuration from the NORD VPN and uploaded it to the router, I entered the credentials and did not change any configuration, I was able to connect to the NORD but after a few hours I saw that I was already disconnected. Then I tried the procedure from NORD VPN - link attached above, but it does not work with this procedure. I have VDSL internet and my router is establishing a PPPoE connection. I will ask for advice. well thank you
 

Attachments

  • VPN1.jpg
    VPN1.jpg
    76.7 KB · Views: 100
  • VPN2.jpg
    VPN2.jpg
    89.8 KB · Views: 95
  • VPN3.jpg
    VPN3.jpg
    78.2 KB · Views: 101
  • VPN4.jpg
    VPN4.jpg
    18.9 KB · Views: 97

eibgrad

Very Senior Member
FYI. In your Routing Policy rules, 192.168.1.1/24 is NOT a valid IP.

Also, if you upload (as in "import") the VPN provider's config file, why the need to add anything to the custom config field? Many times adding things to custom config just breaks things. And in the case of a config file from the VPN provider, it should already have everything you need. That's the whole point!
 
Last edited:

ColinTaylor

Part of the Furniture
You have also mangled three of the lines that you typed into the custom config box which would have prevented the client from starting.
 

Nesalex

Occasional Visitor
Just use the config settings that come with the file that you downloaded from NordVPN (like you did originally). Don't use the settings on that web page.

See RMerlin's comment here: http://www.snbforums.com/threads/setting-up-nordvpn-on-asus-rt-ac68u.68149/post-638446
OK thank you very much for the link I'll try again with the DNS mode set to exclusive. I don't understand how I could miss this thread. I am now connected via VPN and waiting for how long it will work. Thank you again..
 

Nesalex

Occasional Visitor
FYI. In your Routing Policy rules, 192.168.1.1/24 is NOT a valid IP.

Also, if you upload (as in "import") the VPN provider's config file, why the need to add anything to the custom config field? Many times adding things to custom config just breaks things. And in the case of a config file from the VPN provider, it should already have everything you need. That's the whole point!
192.168.1.1/24 I have there because I want all devices on the router to go through the VPN. The exception is 192.168.1.1 for access from the Internet to the WAN and also AIcloud and 192.168.1.197 is the IP of the computer which must go outside the VPN.
 

eibgrad

Very Senior Member
192.168.1.1/24 I have there because I want all devices on the router to go through the VPN. The exception is 192.168.1.1 for access from the Internet to the WAN and also AIcloud and 192.168.1.197 is the IP of the computer which must go outside the VPN.

If you want the entire 192.168.1.0/24 network to use the VPN, you should specify it that way.

Also, adding 192.168.1.1 and binding it to the WAN is NOT going to work the way you think. This is an all too common misconception.

When the router uses the internet, it is NOT bound to the LAN network interface (192.168.1.1). At least not normally. IOW, the source IP from those packets is NOT 192.168.1.1. Rather, those packets are either the source IP associated w/ the WAN (i.e., public IP) or VPN (assigned IP on the tunnel), whichever the router is using by default. And when Routing Policy is enabled, the router's own internet-bound processes are always routed over the WAN.

So in this particular case, the 192.168.1.1 rule is superfluous. It won't work as intended, even if you chose to bind that same IP to the VPN.

In short, what you need is the following:

Code:
192.168.1.0/24 VPN
192.168.1.197 WAN
 
Last edited:

ColinTaylor

Part of the Furniture
Also, adding 192.168.1.1 and binding it to the WAN is NOT going to work the way you think. This is an all too common misconception.

When the router uses the internet, it is NOT bound to the LAN network interface (192.168.1.1). At least not normally. IOW, the source IP from those packets is NOT 192.168.1.1. Rather, those packets are either the source IP associated w/ the WAN (i.e., public IP) or VPN (assigned IP on the tunnel), whichever the router is using by default. And when Routing Policy is enabled, the router's own internet-bound processes are always routed over the WAN.
He's not talking about general router traffic going out of the WAN. He's talking about unsolicited traffic coming in. He says he's allowing remote Web and AiCloud access, which (IIRC) is NATed to the router's LAN address.
 

Nesalex

Occasional Visitor
If you want the entire 192.168.1.0/24 network to use the VPN, you should specify it that way.

Also, adding 192.168.1.1 and binding it to the WAN is NOT going to work the way you think. This is an all too common misconception.

When the router uses the internet, it is NOT bound to the LAN network interface (192.168.1.1). At least not normally. IOW, the source IP from those packets is NOT 192.168.1.1. Rather, those packets are either the source IP associated w/ the WAN (i.e., public IP) or VPN (assigned IP on the tunnel), whichever the router is using by default. And when Routing Policy is enabled, the router's own internet-bound processes are always routed over the WAN.

So in this particular case, the 192.168.1.1 rule is superfluous. It won't work as intended, even if you chose to bind that same IP to the VPN.

In short, what you need is the following:

Code:
192.168.1.0/24 VPN
192.168.1.197 WAN
OK I understand. Now I'm in my work in the office and I'm setting up my router remotely but I'm afraid that if I set up 192.168.1.0/24 VPN
192.168.1.197 WAN I will lose access to the WAN as I lost it at home when I configured it yesterday. When I enter 192.168.1.1/24 VPN + 192.168.1.1 WAN + 192.168.1.197 WAN it works for me exactly as I need it. During the test, on all NORD VPN devices it tells me that I am protected and on 192.168.1.197 it says unprotected. Everything works like this for some time, but after a few hours the connection to the VPN was interrupted. Maybe changing the DNS mode to Exclusive will help ... So I'll try to change it according to your recommended settings?
 

eibgrad

Very Senior Member
He's not talking about general router traffic going out of the WAN. He's talking about unsolicited traffic coming in. He says he's allowing remote Web and AiCloud access, which (IIRC) is NATed to the router's LAN address.

NAT'd or *bound* to the router's LAN ip? If it's the latter, then yes it will be routed over the VPN w/o that "192.168.1.1 WAN" rule, which is why I said "not normally".

Which begs the question, exactly where are these services being hosted? On the router, or elsewhere on the LAN?
 

Nesalex

Occasional Visitor
He's not talking about general router traffic going out of the WAN. He's talking about unsolicited traffic coming in. He says he's allowing remote Web and AiCloud access, which (IIRC) is NATed to the router's LAN address.
So do you think my settings are correct? Everything now works as I need it for about an hour. All I need is to have access from the external internet to my router for configuration and access to the AI cloud and at the same time have my entire all home network under a VPN without a single IP ...
 

ColinTaylor

Part of the Furniture
NAT'd or *bound* to the router's LAN ip? If it's the latter, then yes it will be routed over the VPN w/o that "192.168.1.1 WAN" rule, which is why I said "not normally".
Both. The listening service (e.g. httpd) is bound to the LAN interface as is normal and the incoming connection is NAT'd to the LAN address.
 

ColinTaylor

Part of the Furniture
So do you think my settings are correct? Everything now works as I need it for about an hour. All I need is to have access from the external internet to my router for configuration and access to the AI cloud and at the same time have my entire all home network under a VPN without a single IP ...
I don't know why your connection only lasts a hour. Try using a different NordVPN server.
 

eibgrad

Very Senior Member
OP, it's NOT going to hurt to have the "192.168.1.1 WAN" rule. As I said, internet-bound processes on the router are NOT normally bound to the LAN. But if they are, then yes, having the rule is useful. I certainly wouldn't risk changing it at this point.

I don't use AiCloud, so I can speak w/ authority to that specific service. But given its intended for remote access over the WAN, it seems odd it would be bound to the LAN. Not unless it's somehow integrated into the router's own httpd server, which it seems @ColinTaylor is suggesting.
 

Nesalex

Occasional Visitor
I don't know why your connection only lasts a hour. Try using a different NordVPN server.
It looks good. It's 5 hours behind us and the router still has an active VPN connection ... Today I made one change of settings = the DNS mode SET to Exclusive .. I'll watch it ... Thank you very much :)
 

Attachments

  • VPN5.jpg
    VPN5.jpg
    62.9 KB · Views: 48

eibgrad

Very Senior Member
FYI. I got curious about this AiCloud service apparently being bound to the LAN. It just didn't make sense given it's an internet accessible service. Plus, why the router's httpd server? That's known to be a weak link in the system, and why you're repeatedly warned NOT to expose it for remote access over the WAN. So I got my hands dirty and started digging.

What I found is that AiCloud is using the lighttpd webserver, NOT the httpd server of the GUI. You can tell by dumping the process table.

Code:
8604 admin    15912 S    /usr/sbin/lighttpd -f /tmp/lighttpd.conf -D
8605 admin    11152 S    /usr/sbin/lighttpd-monitor
8712 admin    11592 S    /usr/sbin/lighttpd-arpping -f br0

If you then dump its config file, you'll find it's bound to ports 443 and 8082, configured for *all* network interfaces.

Code:
[email protected]:/tmp/home/root# cat /tmp/lighttpd.conf | grep socket
$SERVER["socket"]==":8082"{
$SERVER["socket"]==":443"{

The fact there is nothing before the ':' means *all* (0.0.0.0). And that is confirmed w/ a dump of the listening ports using netstat.

Code:
[email protected]:/tmp/home/root# netstat -an | egrep ':443|:8082'
tcp        0      0 0.0.0.0:8082            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN

Finally, I was able to access AiCloud over my WAN (port 443), while my OpenVPN client is active, has Routing Policy enabled, and only has the following rule.

Code:
192.168.1.0/24 VPN

But of course, I got locked out of the GUI even though I had it enabled for remote access (just for testing purposes).

What's it all mean?

There's no need to use the "192.168.1.1 WAN" routing policy rule, at least not for the AiCloud service. Again, that rule is only useful if some service is *only* bound to the LAN and you needed remote access over the WAN, for example, the GUI. But you'd be foolish to allow remote access to the GUI anyway. Services are typically bound only to the LAN for a reason, namely, so they aren't readily accessible over the WAN!

All that said, having the "192.168.1.1 WAN" routing policy rule there isn't harming anything. It's just benign. And if everything's working fine right now, just leave it alone. But I've seen too many ppl attempt to use it to force traffic initiated by the router's internal processes over the WAN or VPN, to no avail. It's only going to work when you can reconfigure that process so that it is *solely* bound to the LAN (e.g., transmission, which I've done many times before w/ users).
 
Last edited:

Nesalex

Occasional Visitor
FYI. I got curious about this AiCloud service apparently being bound to the LAN. It just didn't make sense given it's an internet accessible service. Plus, why the router's httpd server? That's known to be a weak link in the system, and why you're repeatedly warned NOT to expose it for remote access over the WAN. So I got my hands dirty and started digging.

What I found is that AiCloud is using the lighttpd webserver, NOT the httpd server of the GUI. You can tell by dumping the process table.

Code:
 8604 admin    15912 S    /usr/sbin/lighttpd -f /tmp/lighttpd.conf -D
8605 admin    11152 S    /usr/sbin/lighttpd-monitor
8712 admin    11592 S    /usr/sbin/lighttpd-arpping -f br0

If you then dump its config file, you'll find it's bound to ports 443 and 8082, configured for *all* network interfaces.

Code:
[email protected]:/tmp/home/root# cat /tmp/lighttpd.conf | grep socket
$SERVER["socket"]==":8082"{
$SERVER["socket"]==":443"{

The fact there is nothing before the ':' means *all* (0.0.0.0). And that is confirmed w/ a dump of the listening ports using netstat.

Code:
[email protected]:/tmp/home/root# netstat -an | egrep ':443|:8082'
tcp        0      0 0.0.0.0:8082            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN

Finally, I was able to access AiCloud over my WAN (port 443), while my OpenVPN client is active, has Routing Policy enabled, and only has the following rule.

Code:
192.168.1.0/24 VPN

But of course, I got locked out of the GUI even though I had it enabled for remote access (just for testing purposes).

What's it all mean?

There's no need to use the "192.168.1.1 WAN" routing policy rule, at least not for the AiCloud service. Again, that rule is only useful if some service is *only* bound to the LAN and you needed remote access over the WAN, for example, the GUI. But you'd be foolish to allow remote access to the GUI anyway. Services are typically bound only to the LAN for a reason, namely, so they aren't readily accessible over the WAN!

All that said, having the "192.168.1.1 WAN" routing policy rule there isn't harming anything. It's just benign. And if everything's working fine right now, just leave it alone. But I've seen too many ppl attempt to use it to force traffic initiated by the router's internal processes over the WAN or VPN, to no avail. It's only going to work when you can reconfigure that process so that it is *solely* bound to the LAN (e.g., transmission, which I've done many times before w/ users).
Wow. Thank you for the extensive description. I am not an experienced user. I have read several warnings on this forum so that I do not allow access to the WAN and graphical interface, but I can be believed that it is so dangerous. If the attack causes me a connection failure OK it is not a problem for me. But if someone can break or bypass the login - login name and strong password, then I will change this setting to be able to log in via the WAN from the Internet to the graphical interface. I thought that using Merlin software and regular updates would be safe for such a WAN connection and to the graphical interface..uff
 

eibgrad

Very Senior Member
My comments really weren't about the efficacy of the AiCloud service, but more the rationale behind the routing policy rules being used. This issue of using the router's LAN ip in the rules is commonly misunderstood.

As far as the Merlin firmware itself, many features (including AiCloud) have nothing to do w/ Merlin. Merlin simply incorporates what ASUS provides as closed source components, then adds his own features and enhancements.

Since we're on the subject of security/safety, I personally would never use something like AiCloud because of how it's implemented. Sure, lighttpd is better than the GUI's httpd, but regardless, these days I don't access *anything* over the WAN except my OpenVPN server. Not http, https, ftp, rdp, nothing. And even then, I run my OpenVPN server on a separate device that's connected to a wifi-enabled AC smart plug so I only have to enable it on-demand.

But everyone's different. Some don't know better, some do and don't care, others are paranoid like me. :)
 

ColinTaylor

Part of the Furniture
@eibgrad What about the remote web access that I was talking about? That's the thing that has httpd bound to the LAN interface and accessed via NAT. Do you not see that on your router?

AiDisk is the same, it's just the normal FTP server accessed by a NAT rule to the LAN address. Although I think the NAT only happens if there's also a port forwarding rule to another internal FTP server. I can't be quite sure about this because Asus has changed this over time and I'm still using John's firmware.

So there appears to be at least two router services that potentially won't work unless that "192.168.1.1 WAN" rule is in place.
 
Last edited:

eibgrad

Very Senior Member
@eibgrad What about the remote web access that I was talking about? That's the thing that has httpd bound to the LAN interface and accessed via NAT. Do you not see that on your router?

AiDisk is the same, it's just the normal FTP server accessed by a NAT rule to the LAN address. Although I think the NAT only happens if there's also a port forwarding rule to another internal FTP server. I can't be quite sure about this because Asus has changed this over time and I'm still using John's firmware.

So there appears to be at least two router services that potentially won't work unless that "192.168.1.1 WAN" rule is in place.

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):

Code:
[email protected]:/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:

Code:
[email protected]:/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

I then checked FTP (port 21) for AiDisk:

Code:
[email protected]:/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.

Code:
[email protected]:/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).

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).

Your best tool is netstat. For any given service, if it's listening on all network interfaces, then you do NOT need the rule.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top