1

Sorry if the title, and tags, are a bit vague, I couldn't figure out the correct terms for it, yet. Please advise, and I will change it.

I'm implementing a STUN server, boxed in a Docker container, which is hosted on Google Container Engine's Kubernetes. The project utilizes load balancers (forwarding rules on GCE) to field external requests to the appropriate ports in the pod/container,

I've routed all traffic coming into eth0 to 2 virtual interfaces(eth0:1, eth0:2) through:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 61214  -j DNAT --to-destination 172.26.0.6

(for completeness sake, the second destination is 172.26.0.7)

A client application reaches it just fine, and so the NAT determination proceeds. This, however, comes to an abrupt halt when the STUN server needs to create a socket and link back to the client application, since the source IP it got is the internal IP of the host VM instance on Kubernetes (e.g. 10.128.0.4). Since no connection was made, the client and server sockets times out.

Is there any way to preserve the actual source address until reaches my server app? I'm open to scrapping the current setup, as long as my request reaches the server and the server gets to make the return connection to the client.

Thank you.

Adam Law
  • 121
  • 4
  • What protocol does communication use? Custom UDP, custom TCP, HTTP/S, etc? – Tim May 07 '17 at 22:36
  • Hi Tim, it's a (purely) TCP implementation. – Adam Law May 07 '17 at 22:37
  • I wonder if proxy protocol could be used somehow. Making a connection outward to the presumed client is unusual, using the connection the client established is more common. – Tim May 07 '17 at 22:59
  • Yeah, IMO, STUN (or any nat traversal technique, for that matter) isn't a run-of-the-mill client-server architecture. It has to be like this, in order to figure out a client's NAT situation, for stuff like hole-punching, to work. There's a part where 3 server-side address:port combinations are used for this classification, requiring the server to create a socket back to the client, for confirmation. I've been researching solutions & so far, what I find adds more complexity e.g source IP preservation provided by cloud service. I'm here wondering if I missed easy solutions that are out there. – Adam Law May 07 '17 at 23:14
  • I'm not a networking expert, so, as someone on the software side, my solution (more like hack), is to pass this data through to the server during one of transactions between client and server. This breaks the specification, however, since all that's meant to be passed are a few bits. I don't want to add something into the mix that won't scale well. – Adam Law May 07 '17 at 23:18

1 Answers1

1

I'm glad to find out that this is one of those uncommon cases in our line of work where the solution exists, and was provided in a timely manner (i.e. just turned beta).

Unfortunately, it's only specific to our context i.e. Kubernetes over GCE/GKE. Users of other platforms (e.g. AWS) will need to employ other solutions, as of the time of this writing.

Adam Law
  • 121
  • 4