Tag Info

Hot answers tagged

2

The firewall won't block already established VPN connections because you have the following rule near the top: -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT That means, connections already in the ESTABLISHED state (from the point of view of the conntrack module of netfilter) will keep passing through. Plus, most likely your INPUT chain has a ...


2

I use tun for this exact use-case in our VPC (we use linux rather than windows, but that aside its the same). So I'd say tun is acceptable in this case. Things to look for are: Is the OpenVPN server within the VPC passing traffic? Most Linux distributions do not by default forward IP traffic. This should be easy to test by running a sniffer on the ...


2

There is no way to tell if anyone on the network path between two points is inspecting the traffic that is passing through, if all you control are the two end points.


1

I'm having a similar issue to this and have been attempting the fix described in this forum post. The idea is that currently when you connect to your public IP address, the return packets are being routed over the VPN. You need to force these packets to be routed over your public interface. These route commands will hopefully do the trick: ip rule add ...


1

iptables -A INPUT -p tcp -s 10.8.0.0/16 -d 192.168.X.X --dport 80 -j ACCEPT Should do the trick... unless you are nat-ing first. You could even add a -i tun0 or something, to limit on the interface name.


1

In my experience, it is not necessary to restart OpenVPN for a new client file in the client config dir. Indeed, from the man page: One of the useful properties of this option is that it allows client configuration files to be conveniently created, edited, or removed while the server is live, without needing to restart the server


1

In the official OpenVPN documentation you can find: [...] --route-nopull When used with --client or --pull, accept options pushed by server EXCEPT for routes and dhcp options like DNS servers. When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still ...


1

The .openvpn you are seeing is not part of the "FQDN" as you call it. Rather, that is indicating which port number the packet is being sourced from. Notice the first packet in that capture is sourced from 192.168.1.10.49566, meaning IP address 192.168.1.10, port 49566. In the case of the openvpn port (port 1149), tcpdump is resolving that to a "friendly" ...


1

Your OpenVPN instance is working on Point to Point mode so your default gateway is not 10.8.0.1. Looking at your client routing table, it seems the OpenVPN client have correctly set up routes, so that the VPN server is your default gateway now (this is instructed by redirect-gateway def1 in server config): Destination Gateway Genmask ...



Only top voted, non community-wiki answers of a minimum length are eligible