[AusNOG] Redirecting a TCP port both directions

Tue Apr 8 14:16:55 EST 2014

If it's a linux box, why not just DNAT it ..

A

From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Geordie Guy
Sent: Tuesday, 8 April 2014 1:30 PM
To: Greg Anderson
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Redirecting a TCP port both directions

It could be.  For now I've got netcat running as a proxy which buys me the time to step through the AWS config and find out if there's a step that doesn't know about the range and is causing the overarching problem.  Thanks guys.

On Tue, Apr 8, 2014 at 12:42 PM, Greg Anderson <ganderson at raywhite.com<mailto:ganderson at raywhite.com>> wrote:
Geordie,

Is it possible that you have missed a rule on:

- The local firewall
- The security group the instance is defined in (bi-directional in VPC)
- A NACL
- Configured route on the VPC to actually send the traffic through your VPC's VPN
- Configured your local VPN endpoint to accept the traffic
- Configured any other firewalls along the way

There are a lot of layers to the onion that you will need to drill through, and I am more likely to side with AWS not doing the wrong thing here, otherwise you would not be the first to hit this problem...

On 8 April 2014 12:21, Geordie Guy <elomis at gmail.com<mailto:elomis at gmail.com>> wrote:
I've got a fault raised at the same time as I'm asking the NOG community for a workaround.

On Tue, Apr 8, 2014 at 12:18 PM, Mark Foster <blakjak at blakjak.net<mailto:blakjak at blakjak.net>> wrote:
Did you raise a fault with AWS? If they've 'misdefined' RFC1918 perhaps they simply need to ... fix it?

On 8/04/2014 2:16 p.m., Geordie Guy wrote:
Yeah OK let me clarify, you didn't miss something, I did.

172.31.1.2 may be inside RFC1918, but I don't think the AWS systems have a copy of the RFC as text and use it, there's another set of rules it uses (that may be a subset of RFC1918 - maybe 10.0.0.0/8<http://10.0.0.0/8>) that are the only ones it'll allow for local routing and down tunnels to on-premise environments.  I think *glaring angrlly at the console*, actually it'll only allow 172.16.0.0/16<http://172.16.0.0/16> down tunnels or locally and sends 172.31.0.0/16<http://172.31.0.0/16> to the Internet.

Either way, I need to redirect a socket.

On Tue, Apr 8, 2014 at 12:11 PM, Mark Foster <blakjak at blakjak.net<mailto:blakjak at blakjak.net>> wrote:
Did I miss something?
Private IPv4 address spaces

The Internet Engineering Task Force<https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force> (IETF) has directed the Internet Assigned Numbers Authority<https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority> (IANA) to reserve the following IPv4 address ranges for private networks, as published in RFC 1918<https://tools.ietf.org/html/rfc1918>:[1]<https://en.wikipedia.org/wiki/Private_network#cite_note-1>
RFC1918 name

IP address range

number of addresses

largest CIDR<https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing> block (subnet mask)

host id size

mask bits

classful<https://en.wikipedia.org/wiki/Classful_network> description[Note 1]<https://en.wikipedia.org/wiki/Private_network#cite_note-3>

24-bit block

10.0.0.0 - 10.255.255.255

16,777,216

10.0.0.0/8<http://10.0.0.0/8> (255.0.0.0)

24 bits

8 bits

single class A network<https://en.wikipedia.org/wiki/Class_A_network>

20-bit block

172.16.0.0 - 172.31.255.255

1,048,576

172.16.0.0/12<http://172.16.0.0/12> (255.240.0.0)

20 bits

12 bits

16 contiguous class B networks

16-bit block

192.168.0.0 - 192.168.255.255

65,536

192.168.0.0/16<http://192.168.0.0/16> (255.255.0.0)

16 bits

16 bits

256 contiguous class C networks

.... pretty sure that 172.31.1.x IP's fit nicely within that 20-bit block that encompasses everything from 172.16.0.0 to 172.31.255.255...

So where you've said 'non-RFC1918' you infact mean 'RFC1918', right? So you're having problems with AWS routing traffic for these RFC1918 addresses to the Internet when that's not what you want?

Mark.

On 8/04/2014 2:07 p.m., Geordie Guy wrote:
Hi Folks,

Working with a B2B partner who has exposed non-RFC1918 addresses 172.31.1.2 and 172.31.1.3 through a VPN tunnel to our environment, and this works fine for hitting a web service down the tunnel from our local networks.  We have a development footprint in AWS that is shanking at this, because an overlying abstraction layer for how AWS S3 instances route means that if it sees a non-RFC1918 range it sends it out to the Internet regardless of any host or other level routes that are specified.  I can set route add 172.31.1.0/24<http://172.31.1.0/24> via a gateway or for that matter the loopback until I go blue in the face and the server will merrily continue to try and find the IP on the Internet.

What I need to do, other than not allow design decisions that involve non RFC-1918 addresses for private networks, is redirect a TCP port (443) from an IP that I *CAN* hit inside our network, to the 172.31.1.0 range down the tunnel, so that 1654287.r.msn.com<http://1654287.r.msn.com> stops scratching his head at the traffic trying to hit him from AWS.

What do I do to accomplish this?  Netcat?  And before anyone says NAT, there's already been enough bad decisions made here.

Regards,

Geordie

_______________________________________________

AusNOG mailing list

AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>

http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

--
[https://lh5.googleusercontent.com/-aWq61wdav6s/UM_3TdCcU9I/AAAAAAAAAEE/JxSBQrF1JzI/w600-h148-p-k/ganderson_footer_small.png]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140408/d9bb9792/attachment.html>