1
Virtual private networks / NAT Reflection problem with vpn tunnel that delivers routable ips
« on: April 13, 2021, 11:36:56 am »
hi,
So I have a specific problem which involves NAT Reflection for a vpn link.
This vpn link is not equiped with a private ip but a public routable ip totally open in terms of port.
So an outbound Nat has been activated on the interface associated to this link.
To link my self-hosted VMs, it's going through internal qemu networks linked to the opnsense VM
So there is an interface between the guests and the vpn link interface.
client at 172.20.0.33 -> interface dhcp 172.20.0.31 -> interface openvpn link with the public ip.
I didn't notice at first the NAT reflexion parameters so it was not activated when I did the prot forwarding but even so it has apparently little importance.
The port forwarding is working great.
The problem is the NAT Reflexion. I can't do a curl from inside the client to the public ip (which means reaching the client itself) and so I can't make certbot from let's encrypt work.
I'm sure it's the NAT Reflexion since we did some testing and by adding a line to /etc/hosts.conf in this debian VM to the actual domain, I have been able to create a certificate. So the problem is not between the Let'sEncrypt servers and the client but well with the client being able to communicate with itself.
Apparently the parameters when activated, don't do a thing.
I don't see any new rules, I tried to recreate one with the port 80 and 443 but it did the same as before.
I know that some will advise to do splitDNS but before you advise that I suggest you do read about yunohost project.
If you read it carefully you will I think clearly understand why create a dozen of zones files with only one to 3 records in it it's more of a hassle. Plus we should be able to rely on NAT Reflexion too even if some of you don't like it.
So what am I missing here? Which rules or parameters should I activated? Is the problem that here are 2 interfaces here ? or is it something else?
Thanks in advance
So I have a specific problem which involves NAT Reflection for a vpn link.
This vpn link is not equiped with a private ip but a public routable ip totally open in terms of port.
So an outbound Nat has been activated on the interface associated to this link.
To link my self-hosted VMs, it's going through internal qemu networks linked to the opnsense VM
So there is an interface between the guests and the vpn link interface.
client at 172.20.0.33 -> interface dhcp 172.20.0.31 -> interface openvpn link with the public ip.
I didn't notice at first the NAT reflexion parameters so it was not activated when I did the prot forwarding but even so it has apparently little importance.
The port forwarding is working great.
The problem is the NAT Reflexion. I can't do a curl from inside the client to the public ip (which means reaching the client itself) and so I can't make certbot from let's encrypt work.
I'm sure it's the NAT Reflexion since we did some testing and by adding a line to /etc/hosts.conf in this debian VM to the actual domain, I have been able to create a certificate. So the problem is not between the Let'sEncrypt servers and the client but well with the client being able to communicate with itself.
Apparently the parameters when activated, don't do a thing.
I don't see any new rules, I tried to recreate one with the port 80 and 443 but it did the same as before.
I know that some will advise to do splitDNS but before you advise that I suggest you do read about yunohost project.
If you read it carefully you will I think clearly understand why create a dozen of zones files with only one to 3 records in it it's more of a hassle. Plus we should be able to rely on NAT Reflexion too even if some of you don't like it.
So what am I missing here? Which rules or parameters should I activated? Is the problem that here are 2 interfaces here ? or is it something else?
Thanks in advance