Vpn with rut241

Hello, IP public obtained, on router 2.x.x.x with custom apn.

With PPTP:

  • “A Connection to the remote computer could not be established, so the port used for this connection was closed.” error.
    Can’t see the user trying to connect from the logs.

Tried with OpenVPN too:

  • Can connect, but when I try to add the network drive windows cant see the server (on 192.168.0.3). From the server webinterface I can see the user connected, but the user can’t reach the samba.

Of course user is enabled for vpn (both types), user is not banned, username and pw are correct. The user can create the samba connection if is the office (LAN).
Port opened from port forwarding page.

What is missing?

Hello,

You cannot reach the device in server’s LAN from RUT. Is that correct?

Make sure you push server’s LAN from the server to RUT. For example, add the following to the server’s OpenVPN config:

push "route 10.0.0.0 255.255.255.0"

Where 10.0.0.0 255.255.255.0 (10.0.0.0/24) is your server’s LAN. This way, RUT will know that it can reach 10.0.0.0/24 network via OpenVPN server.

Kind Regards,

Hello,
uncorrect, I can reach the server while connected with the ethernet.
But I cant reach the server while connected from an another network with a VPN (tried both with PPTP and OpenVPN, with different results as described above.

Below a chart. RED not working, GREEN working.

Kind regards

Hello,

Please check firewall on RUT241. In Network → Firewall → Edit PPTP and OpenVPN zone - allow Input/Output/Forward, and put LAN to ‘allow forward to destination zones’.

Let me know if this helps.

Kind Regards,

Hello,
I dont have “LAN30”, plus the PPTP and OpenVPN are hosted directly from the server at 192.168.0.3.
I have set up the vpn directly from the server and from the router i have done just the port forwarding to the 0.3 for the pptp and openvpn ports
Do I need to do from both? I have understood that I need to use the VPN menù from the router only if I don’t have a way to do it from the server.

Kind regards

Hello,

Apologies, I misunderstood you scenario. I though you have the VPN servers running on RUT.

In this case, it should be enough to simply open the ports on RUT. Delete your current port forwarding rules, navigate to Network → Firewall → Traffic rules and create two new rules. The rules should allow traffic from WAN source zone to LAN zone on destination ports used by you OpenVPN and PPTP (port 1194 for example). You can also create similar rules to allow access from WAN to Device (input). This rule would allow you to access RUT itself. I suggest you take a look at our wiki article about Traffic Rules here.

Kind Regards,

Hello,

image

this is the traffic rule for the pptp. still not working. Something wrong?
PS. Now removing the port forward the pptp says cant connect to the vpn server and the openvpn cant connect at all.
Moreover, how to enable GRE 47 for the pptp?

Kind regards

Hi,

To establish the connection with the server itself over the internet you need the port forwards to your internal server. When I was refering to port forwards, I meant any other rules that you have configured. Apologies for the confusion. Please, check the following:

Ports forwards from WAN to server (192.168.0.3) in LAN on port 1194 (openvpn), and 1723 (PPTP).

Network → Firewall → Automatic helper assignement should be turned ON. (Alternatively, disabled it, edit WAN zone → advanced settings → Conntrack helpers - PPTP VPN.)

If there are still issues, navigate to Network → Interfaces and make sure Mob1s1a1 is at the top (main WAN). Also, you can edit the mob1s1a1 interface → Advanced settings and try lowering MTU. Values to try are 1460, 1360, 1260.

If the issue persists, access the RUT via CLI/SSH with username 'root ', install and run TCPdump to see if packets are reaching the server:

opkg update
opkg install tcpdump
#on mobile interface
tcpdump -i wwan0 port 1723
#on LAN
tcpdump -i br-lan port 1723

If the packets are forwarded to the server, check your configurations on the server itself.

You can also try this command for helpers:

echo "net.netfilter.nf_conntrack_helper=1" >> /etc/sysctl.d/11-nf-conntrack.conf

Kind Regards,

Hello,
recreated the forward as below.

After that I have moved the mob1 to first place as below:

The Automatic H.A. is already ON, and i have added the lan to the destination for the wan zone, as below:

I still have the traffic rules from before as below:


For this point i have tried to disable openvpn and pptp rules, disable all 4, disable the openvpn2 and pptp2 rules and leave all 4 enabled. Still not working.

Below the output of the tcpdump:
image
ctrl+c after 1 min

Tried to lower the MTU too at 1360. Still not working.
After all that I still have the same issue of the start, that is:
PPTP: “A Connection to the remote computer could not be established, so the port used for this connection was closed.” error.
OPENVPN: * Can connect, but when I try to add the network drive windows cant see the server (on 192.168.0.3). From the server webinterface I can see the user connected, but the user can’t reach the samba.

Kind Regards

PS. I tried to connect via pptp 1723 WHILE doing the dumptest and i got this:

root@RUT241:~# tcpdump -i wwan0 port 1723
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wwan0, link-type RAW (Raw IP), capture size 262144 bytes
11:03:58.778035 IP 151.95.YY.YY.57556 > 2.193.XX.XX.1723: Flags [S], seq 1387767636, win 64240, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
11:03:58.779639 IP 2.193.XX.XX.1723 > 151.95.YY.YY.57556: Flags [S.], seq 905427719, ack 1387767637, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
11:03:58.858201 IP 151.95.YY.YY.57556 > 2.193.XX.XX.1723: Flags [.], ack 1, win 515, length 0
11:03:58.858659 IP 151.95.YY.YY.57556 > 2.193.XX.XX.1723: Flags [P.], seq 1:157, ack 1, win 515, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
11:03:58.858945 IP 2.193.XX.XX.1723 > 151.95.YY.YY.57556: Flags [.], ack 157, win 237, length 0
11:03:58.860797 IP 2.193.XX.XX.1723 > 151.95.YY.YY.57556: Flags [P.], seq 1:157, ack 157, win 237, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
11:03:58.949543 IP 151.95.YY.YY.57556 > 2.193.XX.XX.1723: Flags [P.], seq 157:325, ack 157, win 514, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(57556) CALL_SER_NUM(2) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
11:03:58.950948 IP 2.193.XX.XX.1723 > 151.95.YY.YY.57556: Flags [P.], seq 157:189, ack 325, win 245, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(0) PEER_CALL_ID(57556) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
11:03:59.018130 IP 151.95.YY.YY.57556 > 2.193.XX.XX.1723: Flags [P.], seq 325:349, ack 189, win 514, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(0) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
11:03:59.054872 IP 2.193.XX.XX.1723 > 151.95.YY.YY.57556: Flags [.], ack 349, win 245, length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
root@RUT241:~# tcpdump -i br-lan port 1723
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
11:59:37.955257 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [S], seq 260123848, win 64240, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
11:59:37.956328 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [S.], seq 980456617, ack 260123849, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
11:59:38.034249 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [P.], seq 1:157, ack 1, win 515, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
11:59:38.034359 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [.], ack 1, win 515, length 0
11:59:38.034487 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [.], ack 157, win 237, length 0
11:59:38.034551 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [.], ack 157, win 237, length 0
11:59:38.036418 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [P.], seq 1:157, ack 157, win 237, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
11:59:38.113949 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [P.], seq 157:325, ack 157, win 514, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(49772) CALL_SER_NUM(6) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
11:59:38.115315 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [P.], seq 157:189, ack 325, win 245, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(512) PEER_CALL_ID(49772) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
11:59:38.194145 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [P.], seq 325:349, ack 189, win 514, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(512) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
11:59:38.226747 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [.], ack 349, win 245, length 0
12:00:08.258368 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [F.], seq 980456806, ack 260124197, win 245, length 0
12:00:08.354094 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [.], ack 1, win 514, length 0
12:00:08.354304 IP 151.95.YY.YY.49772 > 192.168.0.3.1723: Flags [F.], seq 1, ack 1, win 514, length 0
12:00:08.355394 IP 192.168.0.3.1723 > 151.95.YY.YY.49772: Flags [.], ack 2, win 245, length 0

2.193.xx.xx ip is the office where we have the server with the rut- 151.95.yy.yy is my actual network

Hello,

The logs seem to indicate that PPTP is forwarded and is successul (RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0)). Is the server configured to accept connection from the outside networks?

Could you try running the following command (to see if there’s GRE traffic as well) and try connecting again? Though this should work fine if conntrack helpers are enabled.

tcpdump -i wwan0 'port 1723 or proto 47'
tcpdump -i br-lan 'port 1723 or proto 47'

With OpenVPN you mention that you can connect, but unable to access SAMBA. Are you using hostnames for SAMBA and are those hostnames resolved? Is DNS configured for OpenVPN? Could you check if it works with IP addresses?

Kind Regards,

Hello, for the OpenVPN the qnap create a ovpn directly. Configurated with the DDNS (tried with direct ip too but no difference).
To add the SAMBA connection i just go to the “my computer” folder and press “add network drive”. As path i put " @\192.168.0.3\Server" (its the folder name. Remove @, i just needed to put because this site remove the double \ ).
For the pptp i already have checked the “accept ms-chapv2” option on windows.

Below the logs for the proto 47:

root@RUT241:~# tcpdump -i wwan0 proto 47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wwan0, link-type RAW (Raw IP), capture size 262144 bytes
06:33:14.575506 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
06:33:14.637767 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 0, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:14.696327 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 1, ack 0, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:16.619795 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 2, length 37: LCP, Conf-Request (0x01), id 1, length 23
06:33:17.635880 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 1, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:17.750706 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 3, ack 1, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:19.600238 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 4, length 37: LCP, Conf-Request (0x01), id 2, length 23
06:33:20.638951 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 2, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:20.734389 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 5, ack 2, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:23.614398 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 6, length 37: LCP, Conf-Request (0x01), id 3, length 23
06:33:23.641938 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 3, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:23.696393 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 7, ack 3, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:26.644912 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 4, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:26.698039 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 8, ack 4, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:27.656033 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 9, length 37: LCP, Conf-Request (0x01), id 4, length 23
06:33:29.647925 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 5, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:29.736113 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 10, ack 5, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:31.696019 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 11, length 37: LCP, Conf-Request (0x01), id 5, length 23
06:33:32.650984 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 6, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:32.735781 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 12, ack 6, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:35.654415 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 7, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:35.736155 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 13, length 37: LCP, Conf-Request (0x01), id 6, length 23
06:33:35.736286 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 14, ack 7, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:38.657483 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 8, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:38.774277 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 15, ack 8, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:39.789388 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 16, length 37: LCP, Conf-Request (0x01), id 7, length 23
06:33:41.657829 IP 2.193.XX.XX > 151.95.YY.YY: GREv1, call 64964, seq 9, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:33:41.734271 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 17, ack 9, length 49: LCP, Conf-Ack (0x02), id 1, length 31
06:33:43.775893 IP 151.95.YY.YY > 2.193.XX.XX: GREv1, call 256, seq 18, length 37: LCP, Conf-Request (0x01), id 8, length 23

root@RUT241:~# tcpdump -i br-lan proto 47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
06:36:05.945629 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 0, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:08.936623 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 1, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:11.939620 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 2, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:14.942586 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 3, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:17.945395 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 4, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:20.948412 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 5, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:23.951414 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 6, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:26.954436 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 7, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:29.956622 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 8, length 45: LCP, Conf-Request (0x01), id 1, length 31
06:36:32.959611 IP 192.168.0.3 > 151.95.YY.YY: GREv1, call 64969, seq 9, length 45: LCP, Conf-Request (0x01), id 1, length 31

Screen of the server PPTP vpn config:

Screen of the server OpenVPN vpn config:

The user is already enabled to navigate the folder and to connect via both types of vpn.

If it helps, I can add that i have tried to create rules in the rut for the ftp too, enabled it, enabled the user, but still cant connect via filezilla, error “ECONNREFUSED”.

The error of PPTP, talking about a port closed:

The error of the SAMBA over OpenVPN:

Hello,

If you disable PPTP, does OpenVPN connect then?

For testing, could you try OpenVPN on port 1194?

Few more things to try:

Execute this command to see if it helps with PPTP:

echo "net.netfilter.nf_conntrack_helper=1" >> /etc/sysctl.d/11-nf-conntrack.conf

Anything?

Also, while I have not tried this (since GRE should be handled by conntrack), but you can try adding another port forwading rule where protocol is ‘custom’ and set to 47:

image

Then, check traffic with:

tcpdump -i br-lan 'port 1723 or proto 47'

Kind Regards,

Hello,
First: Now that i added the gre forwarding (which i asked how to add) the pptp is correctly working, thank you.
Second: openvpn still not working. Tried both to disable pptp and to set it to default port 1194.

Kind regards!

Hello,

Conntrack should be able to handle GRE in PPTP connections, but it seems like there were some issues with it in your case.

About OpenVPN. Is the issue with SAMBA only? Are you able to ping or reach other devices in the OpenVPN network? Could you do a TCPDump for that too? You can check OpenVPN interface with ‘ifconfig’.

Kind Regards,

Hello,
if I try to ping 192.168.0.3 after connecting with openvpn i get unreacheble:

"
Esecuzione di Ping 192.168.0.3 con 32 byte di dati:
Risposta da 192.168.0.100: Host di destinazione non raggiungibile.
Risposta da 192.168.0.100: Host di destinazione non raggiungibile.
Risposta da 192.168.0.100: Host di destinazione non raggiungibile.
Risposta da 192.168.0.100: Host di destinazione non raggiungibile.

Statistiche Ping per 192.168.0.3:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
"

Kind regards

Hello,

For OpenVPN, there is no need to open/forward any other ports. Since the device establishes a tunnel, but the destination is unreachable, I suspect that there are routes missing. Are you pushing route to 192.168.0.0/24 network from the Server to the Client?
What are the routes on the client? Does it have a route to the 192.168.0.0/24 network via OpenVPN tunnel? Maybe the client is on the 192.168.0.0/24 network itself?

Please share the routes on the client, as well as OpenVPN configurations on both, server and client.

Kind Regards,

Hello,
sorry, but what do you mean with “share the routes on the client”? What i need to attach?

For the OpenVPN config here you are:
SERVER SIDE:

CLIENT SIDE:
sett1
sett2
sett3
sett4


I just removed the settings about theme

(From the screen you can see that i have set again 443 udp after the test with the 1194)

Kind Regards

Hello,

From the configurations, I do not see any fields where you can specify networks/routes. Thus, could you check on your OpeVPN client machine if the route to 192.168.0.0/24 network is specified with OpenVPN interface? For example, if you are running Windows on the client, you can check routes from command line (CMD):

route print -4

Is there a route to 192.168.0.0/24 (or 192.168.0.3 server)?

Can you do TCP dump on port 1194 on RUT and try pinging from the OpenVPN client?

tcpdump -i wwan0 port 1194
cpdump -i br-lan port 1194

ping from client:

ping 192.168.0.3
ping 192.168.0.3 -l 1200

Are packets coming in?

Kind Regards,

Hello,
meanwhile this is the route tab from my PC where i try to connect with OpenVPN.
Done with OpenVPN program turned off.

image

Kind Regards

Hello,

First of all, the VPN needs to be enabled so that we can see what routes are added when VPN is enabled.

Secondly, I can see that there is already a route to 192.168.0.0/24 via 192.168.0.100 IP. It is likely that when you try to reach 192.168.0.3 SAMBA, the PC sends packets tot 192.168.0.100 instead of the VPN tunnel. As one of the options, you can change the network subnet on which this PC is connected to something different, like 192.168.10.0/24. If there are still issues, please post a screenshot with routes again, but with VPN enabled.

Kind Regards,