triangle routing / DSR (pf change src/dest)

nbari

nbari

I would like to implement DSR (direct server return) this is my current test scenario:

Code: 
Client   <------------------------------------+
src: client IP                                |
dest: 8.208.20.138                            |
       |                                      |
       |                                      |
   (Internet)                                 |
       |                                      |
       |                                      |
    Alicloud                          return traffic to the client from this VM
 EIP: 8.208.20.138                     [ src: 8.208.20.138, dest: client IP]
       |                                           ^
   VM (DHCP)                                       |
+-------------------+                     +----VM Hetzner---+
|IPv4: 192.168.60.89|  <--- wireguad ---> | IPv4: Public IP |
|IPv6: 240b:4005::30|        ipip         | IPv6: Public /64|
+-------------------+     (any tunnel)    +-----------------+


Any ideas how if using PF I could forward the packet from the Alicloud VM to the VM in Hetzner and from there return the response but using instead the IPv4 Public of Hetzner the public IP of alicloud (8.08.20.138) I am aware that BCP38 filter needs to be disabled since eventually from hetzner side they will not allow sending packets from an src that doesn't match my IP
 
do you control the client or is it just a random internet client ?
if you control the client you can set up a tunnel between client and hetzner and set hetzner's tunnel end ip to 8.208.20.138
if you don't control the client then it's problematic because any router upstream of hetzner may block the packet with the source of 8.208.20.138
 
I control the client but I don't want to make the tunnel, I am aware that the packet will get blocked in a public cloud, but in a custom lab I would like to find out first, how to forward/nat so that then the VM could return traffic to the origin.
 
set 8.208.20.138/32 on outside interface on hetzner and try ping -S 8.208.20.138 to another host and tcpdump on the remote host and see if you can see any incoming packets
if that does not work is game over
if it works then on ali cloud try to forward (like in ipfw fwd) the incoming packets to the hetzner end of the ip tunnel (not sure that this part will work) but if it works thats it
 
covacat said:
set 8.208.20.138/32 on outside interface on hetzner and try ping -S 8.208.20.138 to another host and tcpdump on the remote host and see if you can see any incoming packets
if that does not work is game over
if it works then on ali cloud try to forward (like in ipfw fwd) the incoming packets to the hetzner end of the ip tunnel (not sure that this part will work) but if it works thats it
Click to expand...
Any idea of how to do something similar in Linux (Debian) ?
 
So the ping works, but I don't get a response as expected since It arrives on the real server with IP 8.208.20.138, I tried with: nping -S 8.208.20.138 1.1.1.1 and ping -I 8.208.20.138 1.1.1.1 in this box BCP38 is disabled, I indeed notice all the ICMP replies in 8.208.20.138, now I need to check how to forward packets from the FreeBSD box (alicloud) to the Linux VM so that the return traffic goes from there and not from the FreeBSD box
 
for ipfw will be something
add fwd $hetzner_tunnel_ip_end icmp from any to 8.208.20.138
if icmp works change it to match your services
if fwd does not work you may try to nat the packets on both ali cloud and hetzner (change the destination ip twice)
 
You must log in or register to reply here.
Back
Top