[AusNOG] Redirecting a TCP port both directions

Tue Apr 8 13:29:58 EST 2014

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>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> 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> 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) 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 down tunnels or locally and sends 172.31.0.0/16to 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>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 (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 (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 (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 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 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 listAusNOG at lists.ausnog.nethttp://lists.ausnog.net/mailman/listinfo/ausnog
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
>
> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140408/5cc24f36/attachment-0001.html>