Messages

1

19.1 Legacy Series / Re: Site-to-Site IPsec AND IPsec Client behind NAT

« on: May 28, 2019, 02:08:30 pm »

Thank you very much, but may I was a bit imprecisely.

If I set this option, StrongSwan binds only to this interface instead of all that's okay but not sufficient.
Because it still uses all ip addresses that are configured on that interface.

For my scenario, I have multiple WAN IP's on one interface (for several services using the same port) an I would like to have StrongSwan only to listen to just one of this IP's. The one I really use for IPsec.

The only workaround, that came to my mind, would to set this option and configure all WAN IP to a different physical ports. But I don't like the idea to waste one physical port for every IP address just because of the behavior of StrongSwan.

Isn't there a patch that makes StrongSwan to just listen to addresses instead of ports?

Best regards

2

19.1 Legacy Series / Re: Site-to-Site IPsec AND IPsec Client behind NAT

« on: May 24, 2019, 09:27:00 am »

Nobody another idea?

3

19.1 Legacy Series / Site-to-Site IPsec AND IPsec Client behind NAT

« on: May 09, 2019, 10:55:10 am »

Hi,

I have a special problem I think and I hope that my be someone has an idea how to solve this.

On WAN side I have multiple public IPs and I have setup and running one IPsec Site-to-Site tunnel. Let's calls this pimary network.
Beside that there are other networks, let's call one of them guestnet for well guests.
All networks are handeled by the same OPNsense appliance. The guestnet uses a virtual public IP for outgoing traffic which is differend from the main IP used for the primary network NAT.

My wish whould be that clients on the guestnet should be able to start IPsec tunnels from their client devices behind NAT for example to connect to their home locations.
But this does not work  .
Before OPNsense I had an Cisco ASA where this kind of setup was not a problem.

My guess is that the problem is in StrongSwan. Because it binds to all ip addresses on all interfaces I guess that the IPsec answer form the remote site is not forwarded to the client behind NAT.

I tried to change "/usr/local/etc/strongswan.conf" by adding "interfaces_use = "igb0"", but it still binds to all IP addresses including the virtual IP I used for the guest net.

Is there any (easy) way to make this work with OPNsense?

Well I could setup a second OPNsense only for the guestnet ... but this looks bit too big to me.

What if I connect a second interface to the Internet an add my second WAN IP their?
Will not work until manual edit of "strongswan.conf" I guess. But is setup this desirable?

Best regards

4

19.1 Legacy Series / Re: config import problem on new hardware

« on: April 26, 2019, 11:44:08 am »

As mentioned in the thread from hbc this seams to solve the issue in 19.1.6.

Code: [Select]

opnsense-patch 50c25ea
opnsense-patch ea2f217cf


5

19.1 Legacy Series / Re: config import problem on new hardware

« on: April 26, 2019, 11:23:46 am »

Boah, you are great man! Thanks for this link.

What I found in this thread applies to my problem. The "pfTable" on the DEC4610 are empty!

That must be the reason why my rules not work after import.

Many Thanks!

6

19.1 Legacy Series / Re: let out anything from firewall host itself - but is false

« on: April 26, 2019, 08:57:00 am »

Sounds like you need to configure route on "outside" to point to the net behind the OPNsense?

7

19.1 Legacy Series / [Solved] config import problem on new hardware

« on: April 26, 2019, 08:48:29 am »

Hi,

I have setup an running OPNsense 19.1.6-amd64 (FreeBSD 11.2-RELEASE-p9-HBSD / OpenSSL 1.0.2r 26 Feb 2019) on Microsoft Windows 2012R2 Hyper-V Gen2 with several network interfaces to try out OPNsense.

After we are happy with all new OPNsense Rules by replacing our old Cisco ASA we decided to move the HyperV setup to real hardware again. So we ordered an brand new DEC4610.

I exported the config and changed the XML to match the new hardware interfaces (hnX -> igbX), that was no problem.

In my config I have defined around 100 aliases for Port's, Host's and Networks.

After importing the XML to the DEC4610 it looks likte that most rules are not working. On Hyper-V everthing is fine.

After investigating this for several hours it looks like that all aliases containing "Networks" or "Hosts" are ignored by the rules engine. Port-Aliases do work.

For example a have an alias "Net_Clients" containing "192.168.15.0/24", if I use this on on the DEC4610 the logs says "Default deny rule". But if I change the rule to use the native "lan net" (which is the same network as the alias) the the rule works.

This is the case for nearly all of my rules. I'm unwilling to re-create everything from scratch. As sayed above, I have a working configuration. I just want to have this running on the new DEC4610.

Software version on the DEC4610 is the same as on the Hyper-V.

I'm a bit lost, can somebody help please?

Thanks.

Update: Seems to be fixed in 19.1.7.