dear community,
i'm running openvpn-server 2.1.1 on my dd-wrt box at home.. working (nearly) fine so far..
sometimes I need to connect to this server from a network that has "high" access-restrictions.
foreign network-characteristics:
* I have public IP while connected there
* The network does not allow UDP traffic at all
* It blocks well known VPN-ports (1723 for pptp is blocked, 1194 for openvpn is blockedm..)
* But allows anything that is not blocked explicitly
I configured my open-vpn server to use a tcp-port in the upper range (for example 36421) to avoid those restrictions.
If I do so, I can connect for a couple of seconds, the link gets established, but then it gets killed.
When I try to reconnect to that port after my connection has been killed, it's blocked (can't even telnet it then, no answer).
If I change the server-port again, I can connect again for a couple of seconds.
This sounds like Layer7-Filtering to me.
(Layer7 = Inspecting packet-content to determine type)
I was thinking traffic going across the OpenVPN link is fully encrypted... how can it be detected?
Are there some kind of non encrypted keep-alive packets?
Any ideas on how to "keep my connection" secret?
thanks a lot
OpenVPN - Layer7 Filterting
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
- krzee
- Forum Team
- Posts: 728
- Joined: Fri Aug 29, 2008 5:42 pm
Re: OpenVPN - Layer7 Filterting
it is theoretically possible (my theory, which i have never mentioned to anyone) to know a packet stream is openvpn.
I stumbled upon it by accident... it is possible that this has been found by someone besides me... or maybe they are blindly blocking encryption on non-standard ports...
have you tried tcp 443, which is another tcp port where packet streams are expected to be encrypted (https)?
I stumbled upon it by accident... it is possible that this has been found by someone besides me... or maybe they are blindly blocking encryption on non-standard ports...
have you tried tcp 443, which is another tcp port where packet streams are expected to be encrypted (https)?