Messages

Hi,

while setting up an IPsec VPN, I checked the option "This Interface does not require an intermediate system to act as a gateway". The option is under Interfaces --> <interface created by ipsec phase 2 rule>

When checked, a Gateway is automatically created under System --> Gateways --> Single

in my case, it's AZURE-IPSEC_GW. it uses the interface name to construct a gateway name.

However, this name does not meet the restrictions for gateway names, it can not contain a dash!

So now I cannot edit the gateway, it will report "The following input errors were detected:
The name must be less than 32 characters long and may only consist of the following characters: a-z, A-Z, 0-9, _"

Workaround for now is using a very strict naming convention that never contains any other character anytime anyplace anywhere, however I think I should report this for further finetuning the interface. If this is not the place to do so, guide me  :)

Hi,

we have setup a 19.1.9 vmware OPNsense appliance to regulate internet traffic. since we have a few internal hosts that need to be exposed to the internet, we wanted to use some Virtual IP's and Port forwarding to the LAN.
Although we have used this int he past , today there is no way of getting it to work.

Outbound NAT is ok (manual setup) , inbound NAT works  partially - that is, the packets reach my internal hosts. I used Wireshark on the internal hosts to monitor the traffic arriving and leaving. When the host answers , the packets get bounced at the LAN interface of OPNsense.  The OPNsense logs give no clue, ie. they do not even mention the arrival of the returned packets.
I've read there are some issues with VIP's and so, but that should not cause this problem, right ?

There is an any-to-any rule on the tunnel, that should apply on the traffic within the tunnel.

the management should not be influenced by the tunnel's settings, it should remain available on the local LAN interface in my opinion. Right now, as soon as the tunnel is started, the management is broken.
Let us know what your findings are.

did not check that, however TCP is flowing perfectly and the problem stays with very small MTU sizes (i.e. 400).

Hi,

An IPsec tunnel used for a site-to-site VPN does not allow to manage the opnsense instance once the tunnel is up.
The opnsense is on 10.200.5.1: as soon as the tunnel is started, i can only manage the opensense webinterface from the other site: so from the other side of the tunnel, backwards through to tunnel  :-) !

All routing works as expected, only the fact that I can not manage opnsense through the gateway interface address as soon as the tunnel is started, appears odd to me.

the Anti-Lockout Rule is in place and enabled.

has anybody observed this ?

version 17.1.8 on AMD64

[Detailed Settings,]

Excellent !

I tried that, your suggestion did not work at first sight, however, in this menu:

Firewall: Settings: Normalization : Detailed Settings, i added a line for the IPsec tunnel with the "IP Do-Not-Fragment" setting. That improved things quite a bit !

Now it allows most packets through the tunnel . However a certain packet loss is observed when tested with iPerf.

So upstream there is no UDP packet loss (there never was), downstream there is about 20% packet loss.
When the do-not-fragment setting ïs disabled, all packets are dropped, so it DOES have positive effect on the problem, however, quite some packets still get lost. 

That is strange, isn't it ?

Do not set the proxy, set the gateway of your workstation to be the opnsense box.

what did you configure for the WAN interface's ip address ? It should be something that corresponds to the modem.

Hi,

we are running IPSEC to a connect a site to a Fortigate firewall in the datacenter using a site-to-site VPN.
This works fine for normal  client traffic (mostly RDP over TCP) .
It turns out however, that Fragmented UPD is not send from the Fortigate site to the opnsense site .

This used to worked fine when the opnsense was a m0n0wall firewall, , however as soon as ik bring down the m0n0wall and lanuch the opnsense, it stops working. Switching back to the M0n0Wall it works fine again, so it muist be a opsense thing, blocking fragmented UDP for some reason.

opnsense is the latest version.

Any ideas what's wrong ?