Hey ServerFault friends;
AWS released one of their latest products to the public, the Gateway Load Balancer, which allows us to do all kinds of fun things with appliances.
I'm in the process of trying to POC a Squid instance on an EC2 for DNS filtering. I've got the AWS pieces up and running, and the EC2 instance has the geneve interface up, which should be receiving traffic on Eth0. Geneve operates on udp/6081, and encapsulates the traffic. So what I need to do is have the server de-encapsulate the traffic, forward it back to itself on the specified destination port, so that Squid can intercept (tcp/80 or tcp/443 for example) in a transparent proxy format (ideally in a docker container). From there, it egresses out to the Internet via a public IP attached to the ENI.
To the best of my knowledge, in order to make this flow behavior happen correctly, I'm going to need to mangle the hell out of the packet via IPTables. I'm not well versed enough in IPTables to know the ins-and-outs, hence why I'm asking here.
To my understanding, the traffic behavior should be match on destination port udp/6081, send to the IP address of Eth0 (let's say it's 10.10.20.5/24).
The interface adapter should handle the de-encapsulation, and then I believe it needs to forward the traffic to the local loopback address, which should have it egress the server, which hits the output chain (would it though, if it's loopback?).
The local loopback should then have the pre-routing NAT rules to forward tcp/80 to tcp/3129, tcp/443 to tcp/3130, etc., so that the Squid listener can handle it accordingly (permit/deny based on rules).
I know when the server itself is the target, your NAT rules look like:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3130
It's just that geneve tunnel in front that makes me unsure how to start the flow for the rules.