42
edits
Docs/OPNsense: Difference between revisions
m
→WAN
(Created page with "OPNsense is our router/firewall. We have two OPNsense devices, Lasagna and Ravioli. === Firewall Rules === View the WebUI for the specific firewall rules, but some of the more basic/essential ones are: # Management cannot communicate with LAN/WAN (the internet), and LAN cannot communicate with Management. ## Generally, Management should be restricted from everything else. (maybe even other iDrac servers?) ## OOB services tend to be ''super'' vulnerable, there are dozen...") |
m (→WAN) |
||
| (11 intermediate revisions by 3 users not shown) | |||
|
'''For Layer 1 network details, see [[Docs/Cables]].'''
'''For Layer 2 network details, see [[Docs/Switches]].'''
OPNsense is our router/firewall.
We have two OPNsense devices, Lasagna and Ravioli.
=== Management (OOB) ===
{| class="wikitable"
!Subnet
|-
|}
{| class="wikitable"
!Subnet
|-
|}
Servers and Virtual Machines.
LAN cannot communicate with Management.
=== WAN ===
{| class="wikitable"
!Subnet
!Main WAN IP
|-
|141.219.180.64/27
|141.219.180.69
|}
Our public IP subnet under Tech's <code>141.219.0.0/16</code> block.
The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM
=== OpenVPN ===
{| class="wikitable"
!Subnet
|-
|10.10.10.0/24
|}
OpenVPN can be used as a secondary admin/user option compared to wireguard or can be used for homelab routing. This allows devices on a members network to communicate directly with lug devices, depending on what is configured on the user side and the server's side.
{| class="wikitable"
!Subnet
|-
|10.10.11.0/24
|}
All members can request 'user' wireguard configurations to connect to LUG infrastructure. These 'user' configs are restricted to LUG's LAN network only. (due to the aforementioned iDrac exploit issues).
▲# Management cannot communicate with LAN/WAN (the internet), and LAN cannot communicate with Management.
▲## Generally, Management should be restricted from everything else. (maybe even other iDrac servers?)
▲## OOB services tend to be ''super'' vulnerable, there are dozens of [https://github.com/mgargiullo/cve-2018-1207 premade scripts] that instapwn iDRACs and give you a root shell by just pointing them at the IP address.
▲## Because of this, the iDRAC web login interface should only be accessible to anyone you're okay having root on the server.
▲# Wireguard
Neither wireguard config should have access to the internet and are not intended for standard VPN traffic through LUG as an exit.
▲=== Routing ===
Endpoint networks can be configured as needed but OpenVPN may be preferred for this usecase as LUG/users can dynamically change routes/receive DHCP updates.
▲* 10.10.0.0/24 - Management (OOB Management services like [https://www.dell.com/en-us/lp/dt/open-manage-idrac Dell iDRAC] / [https://www.hpe.com/us/en/hpe-integrated-lights-out-ilo.html HP iLO])
=== pfsync ===
▲The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM (so we can't do it like IT and exclusively use publicly routable addresses).
{| class="wikitable"
!Subnet
|-
|10.10.250.0/24
|}
Interface used for High Availability (HA) sync between the 2 firewalls.
Cannot communicate with any other subnet.
== OPNSense ==
▲* 10.10.10.0/24 - OpenVPN
<Rules for access, updates, generating wireguard configs, etc>
▲* 10.10.11.0/24 - Wireguard
▲** 10.10.11.0/25 - Wireguard admin range (access to Management+LAN, no WAN)
▲** 10.10.11.128/25 - Wireguard user range (access to only LAN, no WAN)
| |||