› Forums › Network Management › ZeroShell › OpenVPN struggle.
- This topic is empty.
-
AuthorPosts
-
October 18, 2015 at 6:14 pm #44408
igork
MemberHello,
It seems that I can connect to the VPN from my client. In the beginning, it would freeze my computer and everything would move very slow. I was able to find that VPN connection removed my Default Gateway and it would add the Default Gateway of the VPN connection, but I was not able to connect neither to the Internet nor to any of the LAN addresses.
I made a change and configured OpenVPN to be a default Gateway for VPN and LAN subnets only. It stopped freezing my computer and I am able to connect to the Internet. I still cannot connect to any of the LAN or VPN addresses. I cannot even ping VPN gateway.
Can someone help?
Thank you.October 18, 2015 at 7:37 pm #53921redfive
ParticipantWith default firewall rules, (INPUT and FORWARD to ACCEPT), you will be able to reach everything, if you aren’t able, I’d investigate on the rules, eg. input from VPN99 must be allowed, as well as the forward from VPN99 to … (what you need/prefer)…
RegardsOctober 18, 2015 at 8:02 pm #53922igork
MemberThank you for your reply.
These are the rules that I have on the firewall:
Policy: Drop Chain: Input
1 ETH00 * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 PHYSDEV match –physdev-in ETH00 yes
2 BRIDGE00 * ACCEPT all opt — in BRIDGE00 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
3 WLAN00 * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 PHYSDEV match –physdev-in WLAN00 yes
4 ETH02 * ACCEPT all opt — in ETH02 out * 0.0.0.0/0 -> 0.0.0.0/0 no
5 VPN99 * ACCEPT all opt — in VPN99 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
6 ETH01 * ACCEPT all opt — in ETH01 out * 198.232.221.101 -> 0.0.0.0/0 yes
7 * * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state RELATED,ESTABLISHED yes
8 ETH01 * DROP all opt — in ETH01 out * 0.0.0.0/0 -> 0.0.0.0/0 yesPolicy: Drop Chain: Forward
1 BRIDGE00 * ACCEPT all opt — in BRIDGE00 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
2 ETH00 * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 PHYSDEV match –physdev-in ETH00 yes
3 ETH02 * ACCEPT all opt — in ETH02 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
4 WLAN00 * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 PHYSDEV match –physdev-in WLAN00 yes
5 VPN99 * ACCEPT all opt — in VPN99 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
6 ETH01 * ACCEPT all opt — in ETH01 out * 198.232.221.101 -> 0.0.0.0/0 yes
7 * * ACCEPT all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state RELATED,ESTABLISHED yes
8 ETH01 * DROP all opt — in ETH01 out * 0.0.0.0/0 -> 0.0.0.0/0VPN connection comes from 198.232.221.101 address.
In addition, I cannot disconnect from the VPN. The status usually stays after:
Closing TUN/TAP interfaceAnd nothing happens. The only way to get rid of this issue is to restart the computer.
October 18, 2015 at 8:12 pm #53923igork
Member@redfive wrote:
With default firewall rules, (INPUT and FORWARD to ACCEPT), you will be able to reach everything, if you aren’t able, I’d investigate on the rules, eg. input from VPN99 must be allowed, as well as the forward from VPN99 to … (what you need/prefer)…
RegardsAlso, why I cannot ping my VPN’s IP address of the ZeroShell? Just to explain.
I used default configuration where IP address of VPN99 is 192.168.250.254. DHCP of the VPN is 192.168.250.1-192.168.250.253. Default gateway and DNS are 192.168.250.254.
When I login using VPN client, I received 192.168.250.1 IP address. I cannot ping anything, including 192.168.250.254 address. Message is Destination Host Unreachable.
October 18, 2015 at 8:20 pm #53924redfive
ParticipantUpgrade the vpn client to the latest 2.3.4 x86_64, run it as admin, and if it still doesn’t work, while connected in vpn, open a command prompt and post the output of
netstat -r
RegardsOctober 18, 2015 at 8:38 pm #53925igork
MemberThank you for your reply. I am using 2.3.4 client. This is the output of that command. It seems that ping should go the correct path, but it cannot reach 192.168.250.254 address:
C:Windowssystem32>netstat -r
===========================================================================
Interface List
30…02 50 41 00 00 01 ……PANGP Virtual Ethernet Adapter
23…00 ff ed a6 12 d2 ……TAP-Windows Adapter V9
22…00 ff b0 3b 53 08 ……Juniper Network Connect Virtual Adapter
11…00 50 56 a5 2f 7f ……vmxnet3 Ethernet Adapter
1………………………Software Loopback Interface 1
19…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
12…00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
18…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
25…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
29…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.101.30.1 10.101.30.132 261
10.101.30.0 255.255.255.0 On-link 10.101.30.132 261
10.101.30.132 255.255.255.255 On-link 10.101.30.132 261
10.101.30.255 255.255.255.255 On-link 10.101.30.132 261
24.118.13.106 255.255.255.255 10.101.30.1 10.101.30.132 5
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 192.168.250.254 192.168.250.1 20
192.168.250.0 255.255.255.0 On-link 192.168.250.1 276
192.168.250.0 255.255.255.0 192.168.250.254 192.168.250.1 20
192.168.250.1 255.255.255.255 On-link 192.168.250.1 276
192.168.250.255 255.255.255.255 On-link 192.168.250.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.101.30.132 261
224.0.0.0 240.0.0.0 On-link 192.168.250.1 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.101.30.132 261
255.255.255.255 255.255.255.255 On-link 192.168.250.1 276
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.101.30.1 Default
===========================================================================IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
11 261 fe80::/64 On-link
23 276 fe80::/64 On-link
11 261 fe80::2037:b5b5:4f39:4973/128
On-link
23 276 fe80::a425:9b63:1fcf:c4c1/128
On-link
1 306 ff00::/8 On-link
11 261 ff00::/8 On-link
23 276 ff00::/8 On-link
===========================================================================
Persistent Routes:
NoneC:Windowssystem32>
October 18, 2015 at 8:48 pm #53926redfive
ParticipantSorry, I wrote 2.3.4 , but I meant 2.3.8 …. if you try a tracert -d to 192.168.250.254, or even to 192.168.0.x, which is the result ?
October 18, 2015 at 8:56 pm #53927igork
MemberInstalling newer client fixed all my problems with VPN.
Thank you very much for your help.
October 18, 2015 at 9:14 pm #53928redfive
ParticipantWhile rule 8 (in both input and forward chains) is useful only for logging purpose (packets without a match in previous rules will be dropped anyway, due to the defult action DROP), moving rule n°7 to 1st place, will make things .. faster.
RegardsOctober 18, 2015 at 9:19 pm #53929igork
MemberThank you for the suggestion, but what about rule number 6? If I understand correctly, the system reads rules from the top to bottom. If I set it up like this:
1 ETH01 * DROP all opt — in ETH01 out * 0.0.0.0/0 -> 0.0.0.0/0 yes
2 ETH01 * ACCEPT all opt — in ETH01 out * 198.232.221.101 -> 0.0.0.0/0 yesI think it will never reach the second rule. Am I correct?
Maybe I have to use that Accept rule as number one and Drop as number two?
October 18, 2015 at 9:34 pm #53930redfive
ParticipantActually, with the default action at DROP, you don’t need (unless specific configs) the last rule, the DROP, which is useful only for logging, and yes , the rules, as the ACLs, are processed as ‘top-down’, you have to explicitly allow what you need, and the default action (an implicit deny any) will deny all other packets.
If you simply move the 7 to 1, the 6 will become the 7, and the 8 will be still the 8.
RegardsOctober 18, 2015 at 9:37 pm #53931igork
MemberI understand it and I agree that this is how it should be, but…..
When I run firewall test from ShieldsUP, it detected that I had port 80 opened. I tested and the port was opened, but there are no rules for anything with port 80.
After I added that DROP rule, everything is closed now.
This was the reason for that rule.
-
AuthorPosts
- You must be logged in to reply to this topic.