1

I have:

  • eth0 interface with 10.0.0.41 having public ip 54.x.x.x (will be used for VPN client)
  • eth1 interface with 10.0.0.100 having public ip 57.x.x.x

eth1 is where i am remotely connected using SSH eth0 will be connected to another server as VPN IPsec

because my default routing is eth1, while connecting to VPN it fails cause VPN server only allow ip 54.x.x.x not traffic from 57.x.x.x

Now, how can i tell routing that all traffic going to VPN server address: 212.x.x.x will be sent via eth0 (54.x.x.x) and still have eth1 (57.x.x.x) available for SSH remote access?

EDIT:

enter image description here

EDIT: does amazon allow me to have 2 different subnet public ip to my 2 network interface. it seems like no

enter image description here enter image description here enter image description here enter image description here

EDIT: Amazon EC2 - VPC with multiple subnets

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html

Scenario 1: VPC with a Public Subnet Only - 1 subnet http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario1.html

Scenario 2: VPC with Public and Private Subnets - 2 subnet http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html

Scenario 3: VPC with Public and Private Subnets and Hardware VPN Access - 3 subnet http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html

Scenario 4: VPC with a Private Subnet Only and Hardware VPN Access http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario4.html

EDIT:

Step 1: Amazon EC2 > Scenario 1: VPC with a Public Subnet Only - 1 subnet

Step 2: this will allow 10.0.0.0/24 subnet with 1:1 NAT

Step 3: Now to do the inbound and outbound traffic by-pass we should do:

ip rule add from 10.0.0.41/32 table 1 # outbound
ip rule add to 10.0.0.41/32 table 1   # inbound
ip route add default via 10.0.0.1 dev eth0 table 1

ip rule add from 10.0.0.100/32 table 2 # outbound
ip rule add to 10.0.0.100/32 table 2   # inbound
ip route add default via 10.0.0.1 dev eth1 table 2

Step 4: test it remotely assuming remote pc has: iamremotely_publicip

ping publicip_eth0
ping publicip_eth1

Step 5: inbound test

$ tcpdump -vv src iamremotely_publicip and not dst port 22 -i any

### inbound reply received for eth0
13:29:02.163426 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-41.eu-west-1.compute.internal: ICMP echo request, id 10242, seq 1, length 64

### inbound reply received for eth1
13:24:05.415740 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-100.eu-west-1.compute.internal: ICMP echo request, id 11808, seq 52, length 64

Step 6: outbound test on PC iamremotely_publicip

$ tcpdump -vv src publicip_eth0 and not dst port 22 -i any
$ tcpdump -vv src publicip_eth1 and not dst port 22 -i any

That works without VPN.

2
  • 1
    The title doesn't seem to match your question. What you appear to want is *only 212.x.x.x traffic going out of eth0 and everything else out of eth1 - this would enable the VPN to the other server and ssh access from anywhere.
    – Paul
    Jul 29, 2013 at 5:56
  • Working now: unix.stackexchange.com/a/85133/11085
    – YumYumYum
    Aug 1, 2013 at 1:46

2 Answers 2

1

It's very unclear how your LAN is setup and it's seems rather off.

  • what is eth0/1 part of? A DMZ'ed server? Or is it the default router of your local LAN?

  • What are the actual devices assigned with 54.x.x.x and 57.x.x.x? Are they 2 different physical internet routers? Or PPP link established from this host?

  • You want eth0 be a dedicated interface for an IPsec link to a remote network that has a public facing IP 212.x.x.x is that correct?

  • If eth0 is meant for a dedicated VPN link to a remote VPN network, why is it attached to the local LAN subnet 10.0.0.x at all?

You outght to use different subnet for eth0 and eth1, otherwise it's very confusing and you're bound to have packets being sent from both interfaces because the host thinks they are on the same subnet. If eth0 is meant for a dedicated VPN link only, gives it a dummy subnet like 192.168.200.x. Your local and remote LAN should never be routed to this subnet, they will only use this link inside the VPN'ed tunnel, which will have local private IPs (10.0.0.x).

As long as you have a static route for 212.x.x.x to use eth0, once the VPN link is established, all traffic designated for the remote LAN will use the tunnel and hence eth0, there's no special routing need to be done as long as the IPsec endpoint exists on the primary router on your LAN, all necessary routes should be setup for you.

The problem you are having with the remote VPN server blocking 54.x.x.x is a security restriction solely to do with the remote end. The remote VPN server is expecting traffic from 57.x.x.x only and blocking request from 54.x.x.x. For which, you have to find out why it's doing it. Did you initiate the VPN link using 57.x.x.x? Or is the VPN server restricting access using reverse DNS lookup, and you didn't setup DNS properly so that the VPN link is established from a DNS hostname that resolves back to 54.x.x.x? Is the IPsec link using a SSL certificate tied to a DNS hostname that resolves to 57.x.x.x?

EDIT: Here's the revised suggestion:

  • Ask Amazon to provide a different subnet on the 54.x.x.x link (you can't just assign arbiturary IP on your host and expect Amazon's routers know how to handle it)

  • Setup eth0 with the new subnet and default gateway (say, ip 10.0.2.2 gw 10.0.2.1). 10.0.2.2 is the local IP for eth0, and 10.0.2.1 is the default gateway for this subnet, which resides on Amazon's network.

  • Your host should already have a default route for 10.0.2.0 to use 10.0.2.2 as the interface when you setup eth0, any traffic for 10.0.2.0/24 will skip eth1.

  • setup a static route for the VPN server IP 212.x.x.x to use 10.0.2.1 as the gateway. There should be no need to specify eth0.

  • DONE. When you connect to 212.x.x.x it will automatically use eth0 and gw 10.0.2.1, which in turns goes out to the internet with the 54.x.x.x link

3
  • 1
    In this scenario, you need to understand that the default gateway is assigned at the amazon routers. If both eth0 and eth1 are connected to the same subnet, it doesn't matter if you assigned traffic to go out on eth0, 57.x.x.x is still the default outgoing endpoint for the whole subnet of 10.0.0.x as far as Amazon's routers are concerned. I'm not familiar with specific amazon EC2 comands, but what you need to do basically is to create eth0 with a different subnet, then route 212.x.x.x to eth0 as you have. Traffic going out of here with then use the 54.x.x.x endpoint.
    – goofrider
    Jul 29, 2013 at 9:20
  • 1
    Well the host is also believing that eth0 and eth1 are on the same subnet, that's why it's giving 57.x.x.x inthe header for all packets using the 10.x.x.x subnet. If you want eth0 packets to have differ headers, eth0 needs to be assigned a different subnet with it's own default route. Unless you wanna go off the deep end and rewrite IP headers using IPtables. Can you subdivide 10.0.0.x on the host itself? Like 10.0.0.0/30 for eth1 and 10.0.0.4/30 for eth0? Amazon can still think they are both 10.0.0.0/24, but as long as they are 2 subnets on your end, they can have distinct default routes.
    – goofrider
    Jul 29, 2013 at 9:28
  • 1
    The golden rule: if you don't intend on sharing traffic, don't share IP ranges. Remember that both eth0 and eth1 are DMZ, so your host don't know about nor control 54.x.x.x and 57.x.x.x. A packet is tagged 57.x.x.x as the src IP because that's the endpoint it left the local subnet. And because they are DMZ, the usual IPsec limitation with NAT may still apply.
    – goofrider
    Jul 29, 2013 at 9:40
1

Policyrouting should work with normal setup, not sure if it works with NAT/VPN but I would try something in the lines of:

ip rule add from src 10.0.0.41/32 table 1
ip route add default via 10.0.0.xxx dev eth0 table 1

ip rule add from src 10.0.0.100/32 table 2
ip route add default via 10.0.0.xxx dev eth1 table 2

but I have no idea how Amazon routes these networks and will VPN work trough that setup..

Also you may need to do some arp magic to get those working properly if arp cache isn't cold.

But this should make sure that your traffic from 10.0.0.100 goes out via eth1 and .41 via eth0 so you should be able to able to access it via eth1 if its 1:1 NAT.

Don't test this on anything but test-instance, you might loose network connectivity altogether.

1
  • See my last edit, without VPN inbound/outbound is working.
    – YumYumYum
    Jul 29, 2013 at 17:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .