[AusNOG] Redirecting a TCP port both directions

Tue Apr 8 12:42:52 EST 2014

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/4cddfc70/attachment.html>