Edit: Whilst explaining, I finally figured out the error in my logic. The test ip I was using to route to, is the same IP I was connecting with. Thus messing up my connection the moment I changed routing.
This might be simple, or really complex. I have two EC2 nodes. Both are under my complete control.
I need to route all traffic to a specific IP, lets say 31.1.1.1 from one node via the other. Basically a typical VPN setup where all trafic to 31.1.1.1 is routed via the VPN instead of the regular gateway. Like so.
Client Node --> Server Node --> 31.1.1.1
Client Node --> Default GW --> www.google.com
I want to use and have setup WireGuard for this;
The Server
[Interface]
PrivateKey = -------------------
ListenPort = 51820
Address = 10.20.40.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens5 -j MASQUERADE
[Peer]
PublicKey = -------------------
AllowedIPs = 10.20.40.0/24
The Client
[Interface]
PrivateKey = -------------------
ListenPort = 51820
Address = 10.20.40.2/24
[Peer]
PublicKey = -------------------
Endpoint = x.x.x.x:51820
AllowedIPs = 10.20.40.0/24
I start up Wireguard wg-quick up wg0 on both machines, and they can ping each other perfectly. All seems to work.
I bring down Wireguard on the client machine and edit the allowed IP's bit; AllowedIPs = 10.20.40.0/24, 31.1.1.1/32, I then start Wireguard again. That results in immediately breaking all network connections on the client machine. I can't SSH to it, I can't use RDP or any other network connection. It takes hard rebooting via the EC2 console to reach that machine again.
The offending command is, I think ip -4 route add 31.1.1.1/32 dev wg0 since when I issue that on either client or server machine, I reproduce the netwerk outage.
Is this an issue with AWS EC2? Can I even change the routing on those systems? Or is the command as it stands simply wrong?
Edit: Routing tables and other information, as requested
Before
Server
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default ip-172-31-16-1. 0.0.0.0 UG 100 0 0 ens5
172.31.16.0 0.0.0.0 255.255.240.0 U 0 0 0 ens5
ip-172-31-16-1. 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
Client
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.31.16.1 0.0.0.0 UG 100 0 0 ens5
172.31.16.0 0.0.0.0 255.255.240.0 U 0 0 0 ens5
172.31.16.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
After
Server
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.31.16.1 0.0.0.0 UG 100 0 0 ens5
10.20.40.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
172.31.16.0 0.0.0.0 255.255.240.0 U 0 0 0 ens5
172.31.16.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
Client
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.31.16.1 0.0.0.0 UG 100 0 0 ens5
10.20.40.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
172.31.16.0 0.0.0.0 255.255.240.0 U 0 0 0 ens5
172.31.16.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
I've only masked the real server ip, if that is bothersome, let me know. The other hidden items are just the keys.
Doing route ip route add 31.1.1.1/32 via 10.20.40.1 doesn't result in network issue, but some routing does, these don't break it
ip route add 31.1.1.1/32 via 10.20.40.1
ip route add 8.8.8.8/32 via 10.20.40.1
These do break it
ip route add 31.21.203.46/32 via 10.20.40.1
ip route add 31.21.203.0/24 via 10.20.40.1
