Hi,
I guess SNAT-ing on the destination node should work.
Still, without a compelling use case, it seems
like a broken network to me. You will have packets
in transit with an unroutable/incorrect source address,
among other possible issues. ICMP signalling won't work.
I think TCP wouldn't work
Ivan,
sorry for the formatting, it seemed right on my email editor (gmail).
I cannot do SNAT at the source because the packet would be dropped if it
didn't come from the actual IP of the VM.
So I am doing SNAT at the destination. why do you say I am doing it wrong?
I know it would be ideal to do
On Sun, Sep 16, 2018 at 07:08:58PM -0400, Raffaele Spazzoli wrote:
> sh-4.2# iptables -t nat -n -L Chain PREROUTING (policy ACCEPT) target prot
> opt source destination Chain INPUT (policy ACCEPT) target prot opt source
> destination SNAT udp -- 10.128.2.10 0.0.0.0/0 udp dpt: to:
>
Ivan,
I tried the SNAT idea, and still have issue.
here is an example configuration of one of the nodes:
[Interface]
ListenPort =
PrivateKey = ---
[Peer]
PublicKey = H09cwQeUUly2AIdTAhyr5zvzFK9bED0NYiKgJultYwE=
AllowedIPs = 10.128.2.0/23
Endpoint = 192.168.99.12:31112
PersistentKeepalive =
I'll try to make an example
cluster 1 node 1 has private IP1 and VIP1
cluster 2 node 2 has private IP2 and VIP2
each node uses it's private ip for outbound connections.
each node can receive inbound connection on its VIP.
so the wireguard config file for node1 is going to look like:
[peer]
