@planedrop When I don't specify the peer IP manually I do get authentication failure replies back to the initiator box as well, so seems one pfSense unit isn't actually using it's IP as the identifier when it's supposed to, which is why I think this might be a bug.

Will try to do some more digging but really curious if anyone has seen this before.

An update on this; the above settings still being the same, I cannot get the connected devices to use the firewall/DNS resolver when doing a lookup/attempting to connect to any of the devices on the LAN via hostname. Also attached a screenshot of the DNS Resolver settings in case I'm missing anything. I just get the generic "A server with the specified hostname could not be found" message when trying to connect.

dnsResolverGeneral.png

For reference, the Netgate itself is able to ping anything in the DNS Resolver list by name without any issue:

netgateDNSTest.PNG

I finally got a working test without the issue. Issue only occurs with RADIUS authentication and EAP-RADIUS. EAP-MSCHAPv2 with local user/PSK list does not have the issue.

@samir-elfadil said in ipsec tunnle to virtual ip:

what am I missing out :)

If you tell us, which address you need to access from where and how you can access it from the local firewall and what you have configured currently, maybe somebody can answer your question.

@michmoor 172.25.0.1 is a virtual IP for the satellite, it's routed to rocket which handles the communication with the satellite.

Indeed, if I send packets destined to the the satellite from pfsense B they arrive to rocket and get to their destination, but from site A they don't even reach rocket..

@jlw52761 Please test. Im curious if this is possible.

I had to let it percolate a bit to remember that way back when this was set up the PowerShell script adds a route for the subnet:

Add-VpnConnectionRoute -ConnectionName "name" -DestinationPrefix 10.2.2.0/24

IPsec tab FW blocks from source IP to each subnet work great.

Thanks,

@thewaterbug Excellent tests and performance comparison :-)

Last time i checked, both AES-128 and AES256 (both in CBC and GCM mode) were considered safe since they need HEAVY supercomputertime to be decrypted.
128bit is “possible” to decrypt with modern supercomputers, but not in a anywhere close to usable timeframe. 256bit is not practically decryptable (we are looking at many many years of superc time).

@keyser Fortunately I don't think we are getting any packet loss here, more testing and I'm seeing absolutely zero retransmits so that's good.

Unfortunately though the specific device that needs the high bandwidth is from a vendor and uses their own OS, it's technically Ubuntu but point is I can't login to make any adjustments to it. Might find out if the vendor can do any tuning on it for this remote setup.

It's an appliance that typically is on a local subnet rather than remote so it's definitely not setup for this, so considering it only operates about half as fast as on site, I'm pretty happy lol, just wanted to double check things.

Thanks again for all the insight here, greatly appreciate it!

@mclaborn Ok from there Id check the Routes table, I'd check all your firewall rules, and I'd run a tracert to see if if it going somewhere funky.

Also check your Outbound NAT rules to see if there's a redirect there, too, or maybe you have a 1:1 that is translating the IP to something else.

@jimp must be something else… Site-to-Site has remote address set.
I've checked P2 as well vor both VPNs. They have the correct values for their P1 set.

IPsec Tunnel Config.png

@nick-loenders
Anyway, if you have sequenced subnets like these you can embrace them in the p2 using an appropriate mask. But with a local LAN of 10.0.1.0/24 you run into risk of overlapping.

So if the LAN here is 10.0.1.0/24 you could only merge tunnel 2 and 3 by stating 10.0.2.0/23 as the remote network.

If you have control over all involved site you should consider this when designing the networks.

Yep VTI work without issues with AWS/BGP