At my site, I am using openvpn to connect two VPCs in Amazon. I will call them VPC1 and VPC2. VPC1 is connected to the company network via a PaloAlto appliance. Most traffic works as we expect, except that 1) people who connect wirelessly to the company network can connect to VPC1 but not VPC2 2) people logging in remotely to the company network with a VPN client can also connect to VPC1 but not VPC2 Because the only thing standing between VPC1 and VPC2 is openvpn, we are suspecting that's where the problem is, We've added routes for both of these in openvpn and the relevant Amazon VPC routing tables. But so far we haven't been able to explain why this traffic isn't being forwarded over the openVPN when everything else is. I haven't seen anything in openvpn logs to shed light on this either. I'm pasting my openVPN configs below: (edited these to remove sensitive information) The openvpn node in VPC1: [code] # Port to use: 1194 is the official IANA port number port 1194 # Use a dynamic tun device. dev tun # Remote peer and network remote 52.12.11.8 route 10.200.0.0 255.255.252.0 # Configure local and remote VPN endpoints ifconfig 169.254.255.1 169.254.255.2 # The pre-shared static key secret awsdev.key log-append /var/log/openvpn.log verb 4[/code] The openvpn node in VPC2: [code] # Port to use: 1194 is the official IANA port number port 1194 # Use a dynamic tun device. dev tun # Remote peer and network remote 54.86.101.184 route 10.200.255.0 255.255.255.0 # Configure local and remote VPN endpoints ifconfig 169.254.255.2 169.254.255.1 # The pre-shared static key secret awsdev.key route 172.30.0.0 255.255.240.0 route 172.30.22.0 255.255.255.0 route 172.37.0.0 255.255.252.0 route 172.37.52.0 255.255.254.0 route 172.33.0.0 255.255.255.0 route 192.168.199.0 255.255.255.0 route 192.168.1.0 255.255.255.0 [/code] The 192.168.199.0 and 172.37.52.0 subnets above are the ones that are unable to access VPC2

openvpn working except for 2 subnets

asmolar

At my site, I am using openvpn to connect two VPCs in Amazon. I will call them VPC1 and VPC2.

VPC1 is connected to the company network via a PaloAlto appliance.

Most traffic works as we expect, except that
1) people who connect wirelessly to the company network can connect to VPC1 but not VPC2
2) people logging in remotely to the company network with a VPN client can also connect to VPC1 but not VPC2

Because the only thing standing between VPC1 and VPC2 is openvpn, we are suspecting that's where the problem is, We've added routes for both of these in openvpn and the relevant Amazon VPC routing tables. But so far we haven't been able to explain why this traffic isn't being forwarded over the openVPN when everything else is. I haven't seen anything in openvpn logs to shed light on this either. I'm pasting my openVPN configs below:
(edited these to remove sensitive information)

The openvpn node in VPC1:

# Port to use: 1194 is the official IANA port number
port 1194

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 52.12.11.8
route 10.200.0.0 255.255.252.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.1 169.254.255.2

# The pre-shared static key
secret awsdev.key

log-append /var/log/openvpn.log
verb 4

The openvpn node in VPC2:

# Port to use: 1194 is the official IANA port number
port 1194

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 54.86.101.184
route 10.200.255.0 255.255.255.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.2 169.254.255.1

# The pre-shared static key
secret awsdev.key

route 172.30.0.0 255.255.240.0
route 172.30.22.0 255.255.255.0
route 172.37.0.0 255.255.252.0
route 172.37.52.0 255.255.254.0
route 172.33.0.0 255.255.255.0
route 192.168.199.0 255.255.255.0
route 192.168.1.0 255.255.255.0

The 192.168.199.0 and 172.37.52.0 subnets above are the ones that are unable to access VPC2

SomeGuy

Check out the openvpn option "--iroute" and use of ccd on servers to add the iroute options based on CN-based CCD files for vpn server connections.

iroute is for internal routing within openvpn so it knows to route traffic through interfaces that the OS externally has configured for routing.

Think of iroute as a kind of extra routing table for application-based routing in openvpn.

See the man page for details.

TinCanTech

Looking at the OP setup, there are some fundamental flaws in the approach ..

For that reason: tincanteksup <at> gmail .. if you get hopelessly lost.

asmolar

SomeGuy wroteCheck out the openvpn option "--iroute" and use of ccd on servers to add the iroute options based on CN-based CCD files for vpn server connections.

iroute is for internal routing within openvpn so it knows to route traffic through interfaces that the OS externally has configured for routing.

Think of iroute as a kind of extra routing table for application-based routing in openvpn.

See the man page for details.

Thanks for the response. I looked up iroute examples and tried to set some up. But when I do, openvpn fails to restart without giving a clear reason why in the log, even at the highest verb level. Can you give an example of how it's supposed to work?

TinCanTech

asmolar wroteopenvpn fails to restart without giving a clear reason why in the log

The log will give the reason, although you may not understand that reason .. that is what logs are for.
Please paste the sanitized log at --verb 4

asmolar

Now I see:

Options error: option 'iroute' cannot be used in this context

I also see that it should be put in a ccd / client-config-directory. However this is running as a peer to peer/ lan to lan vpn. They are not handling any clients directly. So using that terminology is confusing in this context

SomeGuy

If you have two VPN servers, and one connects to the other, then the one connecting is the client to the other which is a server.

You write:

Because the only thing standing between VPC1 and VPC2 is openvpn, we are suspecting that's where the problem is

Assuming your claim is true, OpenVPN connects VPC1 to VPC2, so one of these is a client to the other.

If the client has any extra subnets that the server does not yet know about, then when the client connects to the server, the server needs to know that it should internally route traffic to that subnet through that client's link on connection. This becomes that client's CCD on the VPN server is is connecting to.

I think TinCanTech's suggestion on logging with "verb 4" was not just for you do ramp up logging verbosity to see for yourself, but for you to post sanitized logs in the thread for examination.