1

I have set up two NAT boxes in two separate AWS accounts and given the necessary security group permissions to allow both instances to talk to each other.

In account A I have a service that needs to talk to a service in account B. We are looking to achieve this through cross-account peering, however we can't automate this process so we are setting up a NAT instance in each account with a permanent peering connection.

We need these NAT instances to route all traffic from the application in account A to the application in account B.

I believe it's going to be iptable rules but after a lot of searching I've yet to find a definitive answer.

NAT 1 ipconfig:

 eth0      Link encap:Ethernet  HWaddr 06:FF:01:29:D1:21
              inet addr:172.32.34.87  Bcast:172.32.34.255  Mask:255.255.255.0
              inet6 addr: fe80::4ff:1ff:fe29:d121/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
              RX packets:5198 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2136 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:5160072 (4.9 MiB)  TX bytes:262514 (256.3 KiB)

eth0:0    Link encap:Ethernet  HWaddr 06:FF:01:29:D1:21
          inet addr:172.0.0.0  Bcast:172.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1

NAT 2 ipconfig:

eth0      Link encap:Ethernet  HWaddr 0A:5F:05:58:5D:FF
      inet addr:172.32.2.219  Bcast:172.32.2.255  Mask:255.255.255.0
      inet6 addr: fe80::85f:5ff:fe58:5dff/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
      RX packets:32937 errors:0 dropped:0 overruns:0 frame:0
      TX packets:5062 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:41548363 (39.6 MiB)  TX bytes:412053 (402.3 KiB)

iptables -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

App with 10.x.x.x ifconfig:

eth0      Link encap:Ethernet  HWaddr 0a:75:f6:ee:f9:9f
      inet addr:10.105.5.51  Bcast:10.105.5.255  Mask:255.255.255.0
      inet6 addr: fe80::875:f6ff:feee:f99f/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
      RX packets:3098043 errors:0 dropped:0 overruns:0 frame:0
      TX packets:1907079 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:1593259614 (1.5 GB)  TX bytes:272469079 (272.4 MB)

And it just has the default iptables set up.

Ste-3PO
  • 11
  • 3
  • Can you provide sample IP configs? – CIA Nov 09 '15 at 13:09
  • Is that any help? Can change it if it's no use! – Ste-3PO Nov 09 '15 at 13:37
  • Where's the `10.0.0.0` info? – CIA Nov 09 '15 at 15:17
  • Sorry, added them now. – Ste-3PO Nov 09 '15 at 15:24
  • Each server is on it's own account, right? How are the two sites connected to each other? VPN? Or are they just able to access each other over the Internet by public IP? – CIA Nov 09 '15 at 21:27
  • We've created a NAT instance in each account that we've manually peered. Then we can deploy services and use a lambda function to peer with the NAT in the account of the new service. We just haven't figured out the routing to allow the two NATs to send traffic from a service in one account to talk to the service in the other account. – Ste-3PO Nov 09 '15 at 21:37
  • I'm assuming `eth0:0` is supposed to be your bridge between `NAT1` and `APP`? Do you have something similar set up on `APP`? – CIA Nov 09 '15 at 22:01
  • We don't. I was hoping the peering connection with the NAT in the app account would be sufficient to route traffic between the app and the NAT and that it would just be the routing between the two NATs that would be problematic (which it has been!) – Ste-3PO Nov 10 '15 at 09:50
  • Does this apply to what you're trying to do? http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html – CIA Nov 10 '15 at 13:57
  • It certainly applies but our solution is three peering connections between four VPCs across two accounts and getting traffic from the app at one end to the other is proving problematic. – Ste-3PO Nov 10 '15 at 14:34
  • Do you have overlapping IP ranges in the 2 VPC's? If not, you are overcomplicating this You don't need NAT. – smithian Nov 12 '15 at 00:48
  • The complication arises from the fact that we can't automate our deployment with a cross-account peering connection as we need to manually accept the connection in the other account. AWS architects have recommended a solution to us, we'll test it out and we'll share it on here if it works out. – Ste-3PO Nov 12 '15 at 11:48

0 Answers0