You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.
If you do finish the rest of the steps then you can also use your Lightsail instance for Selective Routing as well.
Once you have Wireguard setup and want to forward the connections to another system. You'll create NAT Port Forward rules. When you do this you do NOT want to automatically create a firewall rule to allow the traffic. If you do that you the response traffic will end up going out the default WAN. Instead you want to manually create the rule and under Advanced in the rule you want to set the reply-to field to be the Wireguard gateway.
Took a while to find it and credit goes to opn61a: https://forum.opnsense.org/index.php?topic=27413.msg133370#msg133370
The other benefit of this is that the end system is going to see the real client IPs. Instead of getting the MASQUERADE IP if needing to forward to another system.
Motivation
Why are we doing this?
Another method of configuration that keeps all traffic coming in/out of my network centered on OPNSense
What use cases does it support?
Ability to also use the Wireguard tunnel to route traffic outbound from your network avoiding ISP snooping
What is the expected outcome?
Global domination!
Potential conflicts / foreseeable issues
Wireguard support in OPNSense and even pfSense is not built in yet so this is I guess a works but might have issues kinda thing. OPNSense was a bit trickier to get this working with having to manually create the firewall rule so traffic would go out the right WAN interface, not sure if this would be different using an OpenVPN tunnel. pfSense on the other hand appears to not have the same issue with the firewall rules and those could be automatically managed when creating the NAT Forwards.
Additional Context
Thank you for the work you've done!
The text was updated successfully, but these errors were encountered:
Terms
Summary
Implemented this with AWS Lightsail and OPNSense as the client so wanted to pass on some notes for it.
In the PostUp/Down lines you want to use the internal IP of the Lightsail instance.
For OPNSense:
Setup Wireguard and configure a new interface for it. You only need to follow steps 1-6: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
Once you have Wireguard setup and want to forward the connections to another system. You'll create NAT Port Forward rules. When you do this you do NOT want to automatically create a firewall rule to allow the traffic. If you do that you the response traffic will end up going out the default WAN. Instead you want to manually create the rule and under Advanced in the rule you want to set the reply-to field to be the Wireguard gateway.
Took a while to find it and credit goes to opn61a: https://forum.opnsense.org/index.php?topic=27413.msg133370#msg133370
The other benefit of this is that the end system is going to see the real client IPs. Instead of getting the MASQUERADE IP if needing to forward to another system.
Motivation
Why are we doing this?
Another method of configuration that keeps all traffic coming in/out of my network centered on OPNSense
What use cases does it support?
Ability to also use the Wireguard tunnel to route traffic outbound from your network avoiding ISP snooping
What is the expected outcome?
Global domination!
Potential conflicts / foreseeable issues
Wireguard support in OPNSense and even pfSense is not built in yet so this is I guess a works but might have issues kinda thing. OPNSense was a bit trickier to get this working with having to manually create the firewall rule so traffic would go out the right WAN interface, not sure if this would be different using an OpenVPN tunnel. pfSense on the other hand appears to not have the same issue with the firewall rules and those could be automatically managed when creating the NAT Forwards.
Additional Context
Thank you for the work you've done!
The text was updated successfully, but these errors were encountered: