Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - rgradert

#1
It is VTI

V2 Key Exchange



Local Site Opnsense
LAN - 172.19.19.0/24

Phase 1
Mutual PSK
Local IDWAN IP Address
Peer IDWAN IP Address
Encryption AES 256
HashSHA 256
DH14
Lifetime86400

Phase 2
Mode: VTI
Local Address
10.242.10.1
Remote Address
10.242.10.2

IPSEC Interface assigned and enabled.

Remote subnet 10.1.10.0/24 static routed to automatically generated 10.242.10.2 gateway.
10.1.10.0/24   REMOTE_VTI_TUNNEL - 10.242.10.2


Remote Site Netgate
LAN - 10.1.10.0/24

Phase 1
Mutual PSK
Local IDWAN IP Address
Peer IDWAN IP Address
Encryption AES 256
HashSHA 256
DH14
Lifetime86400

Phase 2
Mode: VTI
Local Address
10.242.10.2
Remote Address
10.242.10.1

IPSEC Interface assigned and enabled.

Remote subnet 172.19.19.0/24 static routed to automatically generated 10.242.10.1 gateway.


I have Firewall > Rules > IPSec > Any/Any inplace on both sides.

I can ping from the Firewall to the peer IP from both sides. And my IPSec is up.

On the near side, I trace route getting these results:
C:\Windows\System32>tracert 10.1.10.1

Tracing route to 10.1.10.1 over a maximum of 30 hops

  1     3 ms    <1 ms    <1 ms  172.19.19.1
  2    <1 ms    <1 ms    <1 ms  c-xx-xx-xx-xx.unallocated.comcastbusiness.net [xx.xx.xx.xx]
  3     *        *        *     Request timed out.
  4  xxxxxxxxxxxxx.xxxxxxx.il.chicago.comcast.net [xx.xx.xx.xx]  reports: Destination net unreachable.
  5     *        *        *     Request timed out.

Remote side I at least get a time out indicating that I'm not pushing RFC 1918 out the WAN interface.
C:\Users\phoenix>tracert 172.19.19.1

Tracing route to 172.19.19.1 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  10.1.10.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *     ^C


On my remote firewall (Netgate) I am getting routes populated:
172.16.0.0/12   10.242.10.1   UGS   12   1400   ipsec2

But on my near firewall this is not the case, where 10.1.10.0/24 is missing all together.



After digging around, I discovered that the gateway was sent to far. Which I don't remember ticking, but unticking this and saving resolved the issue. Once the gateway was present, the route was up and traffic flowing.
#2
I have an IPSEC tunnel established. On the far side (Netgate appliance) I have traffic properly routing local net to remote net. On the near side, I cannot get a ping to the remote net.

My trace route shows the traffic hit the firewall and hop out to the ISP. As if the installed route isn't installed.

Does anyone know how I can test this further? First thing that comes to mind is to reboot the firewall but I cannot do that at this time.
#3
Virtual private networks / Re: Advices on my new setup
September 25, 2024, 11:31:15 PM
You are on the right track, I would recommend looking at
https://docs.opnsense.org/manual/nat.html#one-to-one

The OPNsense documentation doesn't look like it covers this just yet.

You could also check out the Netgate documentation for this as it is almost the same.

https://docs.netgate.com/pfsense/en/latest/nat/1-1.html


I personally use a WAN aggregator for this with multiple firewalls for different network segments and private APN stuff through IPSEC/BGP.
#4
Hello,

To preface, I have an old Netgate appliance that is failing. Mission critical life safety equiment resides on this network so downtime would need to be limited heavily. As a result, we are standing a new OPNsense firewall up adjacent to the old network. All new Firewall, Switches, VLANs, etc etc.

Vlans are created with any/any on the new FW. Wireguard established for mobile devices. IPSEC established for LAN to LAN traffic between the networks. Tunnels are up and working. Devices ping, some limited services are available.

No domain services can be established. The goal being to stand up a new DC and replicate it to the old. Then slowly move all network devices over to the new system. Once complete, move the DCs over to the new network. Hopefully providing minimal downtime.

Anyone have experience with this.

For one, there is a 'main switch' as the primary gateway with a 0.0.0.0/0 default route to the old firewall. This created the asymmetrical routing issue resulting in default deny rules playing goalie. NoW that is sorted but services still cannot be established.

#5
Quote from: NW4FUN on December 07, 2022, 04:24:34 PM
That's not the case as testing was made while on Wi-Fi...however, even when off WLAN, it automatically initiates a VPN tunnel into the FW routing all traffic through it.

I clearly understand that a VPN is utilized to keep all traffic routed through the firewall regardless of connection.

What's the confusion?