OpenVPN struggle.

Home Page Forums Network Management ZeroShell OpenVPN struggle.

This topic contains 10 replies, has 0 voices, and was last updated by  igork 3 years, 11 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #44408

    igork
    Member

    Hello,

    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.

    #53921

    redfive
    Participant

    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)…
    Regards

    #53922

    igork
    Member

    Thank 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 yes

    Policy: 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/0

    VPN connection comes from 198.232.221.101 address.

    In addition, I cannot disconnect from the VPN. The status usually stays after:
    Closing TUN/TAP interface

    And nothing happens. The only way to get rid of this issue is to restart the computer.

    #53923

    igork
    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)…
    Regards

    Also, 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.

    #53924

    redfive
    Participant

    Upgrade 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
    Regards

    #53925

    igork
    Member

    Thank 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:
    None

    C:Windowssystem32>

    #53926

    redfive
    Participant

    Sorry, 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 ?

    #53927

    igork
    Member

    Installing newer client fixed all my problems with VPN.

    Thank you very much for your help.

    #53928

    redfive
    Participant

    While 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.
    Regards

    #53929

    igork
    Member

    Thank 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 yes

    I 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?

    #53930

    redfive
    Participant

    Actually, 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.
    Regards

    #53931

    igork
    Member

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

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.