@felipefonsecabh said in Access service in device connected via IPSEC trought public IP:

I have change local network to Any to carry traffic from any external IP?

Yes, if you are using policy based IPSec and need to keep using that. The policy has to match that traffic and the source IP could be any IP.

But if you do that it will match traffic at the other end for 'any' destination. All traffic from site1 will go over the IPSec tunnel. Which you probably don't want.

A route based VPN tunnel of some sort would give you more options.

@Topogigio the problem persists. After a few days pfSense stops binding the IP address on the established tunnel interface.
I've started to build a new opnSense gateway, but if there is some pfSense solution I'll be happy

@felipefonsecabh said in Make a Túnnel trought IPSSEC and OpenVPN using PFSense:

Router of External Access can ping DVC1

What source IP does it use for that?
To pass the IPSec tunnel it must be in he 192.168.15.0/24 subnet.
In which case it can only be the External Access router blocking traffic clients on it's LAN. Or potentially redirecting traffic past the IPSec tunnel?
What is that device?

Steve

@mebert
Consider that you have to state the remote domain if you client uses another search domain, what I assume.

So if you want to request the remote host name is "host" and its domain is "local" you need to type "host.local" to access it.

@timatleeTry turning the PFS key group on P2 to off and see what happens. I have a couple of IPSec connections with Fortigates, 1 with 4 SA's but that one has PFS key group set to off. Unless I am mistaken, by default, the DH for P2 inherits the DH from P1 unless specified differently.
I also set my time lifetime 10% higher than the FortiGate, which seemed to help a lot.

Até agora, o que eu consegui:
Fui em Firewall -> Virtual IPs -> IP Alias, e criei da seguinte forma:

172.25.16.1/24

Daí usei essa faixa como Phase2 da configuração do IPSec com a concessionária.

Daí a concessionária consegue pingar normalmente 172.25.16.1, que é o PFSense.

Daí criei um NAT 1:1 da seguinte forma:

Interface: WAN
External Subnet IP: 172.25.16.2 (endereço virtual do "Device" que é o dispositivo que quero enxergar)
Internal IP: Any
Destination: 192.168.102.10
NAT Reflection: Enable

Porém a concessinária não recebe o ping desse endereço. Alguém tem ideia do que está faltando, ou como posso fazer esse redirecionamento?

@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.

@viragomann I thought it would not work because the additional encryption domains, are not local to the Sophos either
But thanks, I will give it a try.

UPDATE:

I've been doing some tests trying to know where the problem is and it seems that finally it comes from WAN interface. I configured first WAN but until I configured the IPSEC tunnels the problem didnt appear.

Today I reinstall a fresh pfsense and first of all I configured the tunnels with no problems and when I configured the WAN the problem start. If I enable WAN with DHCP or Static IP without a gateway it works everything fine, when I choose a IPv4 Upstream gatewy then return the problem.

At this point this topic can be closed.

@sdedurana a error in config. Solved. Please close.

@keyser Oof. Sounds like I'm in unsupported configuration territory here.

I'll see how it performs in a lab.

@joshopkins
Seems all the settings you did are correct, apart from the push-route commands in the default options. These do the same as the "local networks" setting does, which is the preferred way. You shouldn't have both settings.

Ensure that the access is allowed by rules on all incoming interfaces. Means on the OpenVPN interface at B and on the IPSec of A and C.

To see what's going on, sniff the traffic on the involved interfaces, while you try to access a remote IP from an OpenVPN client.

Wanted to add a bit more info here as this issue remains even after upgrading to 2.6.0 today.

My tunnels are IKEv2 in VTI mode.

Under Phase 1 Advanced Options, I set "Child SA Start Action" to "Initiate at start (VTI or Tunnel Mode)"
and
"Child SA Close Action" to "Restart/Reconnect"

Under Phase 2 > Keep Alive, I use a host on the other side of the tunnel with Keep Alive "Enable periodic keep alive check".

The tunnels do not establish if I shut down the MASTER CARP node or "Enter Persistent CARP Maintenance Mode" on the MASTER CARP node. I have to click Connect to manually establish the tunnels.

Seeing these messages in the IPsec System Log
charon[43289]: 04[CFG] trap not found, unable to acquire reqid 5002

Have anyone else seen this issue?

@shahidge4
The tcpdump from WAN is pretty useless, since the connection is established already.

Your P2 has a single remote IP. So the VPN will only allow access to this one.
Do a packet capture on the IPSec interface.

Ensure that the remote host does not block access from the remote network.

So the P2 will effectively end up being (in my example) 10.200.10.0/24 to 10.100.10.0/24.
Each side 'hides' it;s local 10.10.10.0/24 subnet behind another, same sized, subnet. You could use any unused subnet for that I just chose 10.100.10.0 and 10.200.10.0.

So on each side that would be the Binat address.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

However if you do not need access between the two subnets dircetly but only from the pfSense_1 OpenVPN subnet this becomes easier. You only need to BiNAT on the pfSense_2 side like:

Screenshot from 2022-05-12 14-02-05.png

On the pfSense_1 side the P2 would be just be 172.10.10.0/24 to 10.100.10.0/24

To access the remote side VPN clients would need to use the equivalent NAT address.

Steve

Merci @nicolas-R je vais tester t'as solution.

Well according to this documentation NHRP via FRR is not available for FreeBSD. 😞

http://docs.frrouting.org/en/latest/overview.html#feature-matrix

@rtw915 said in WAN optimization/acceleration:

Now the SQL team needs me to find a way to improve SQL linked server transfer rates to synchronize transactions.

This will bring you back to the initial wan accelerator solution.
The only other possible solution is to redesing the db subsystem, utilizing some way of sql replication, taking into consideration propagation delays

@craigerr1 is P2P? Mobile?
Have u open the rules in both sides to allow traffic on your firewalls->rules->ipsec?
Regards!!!

Hello,

Kind reminder :)

https://forum.netgate.com/topic/163221/constraint-check-failed-rule_crl_validation-is-stale-but-requires-at-least-good/3

Same issue as this one, which had no responses.

@lst_hoe

@bp81 I believe we have found the resolution, and I wanted to post it here for anyone else encountering the issue.

In our DNS forwarder, we had a domain override set for our company's domain. This is the same domain in the hostname for the remote gateway listed above. The domain override was pointing at a DNS server that is not accessible without the tunnel up. Clearly this was causing the IPSec service to fail repeatedly to establish its tunnel.

So there was a misconfiguration on our part which we have fixed. I still maintain that it's a bug if the ipsec service causes the web gui to crash / become unresponsive even when it's a self induced failure state due to misconfiguration. I understand it's possible this may be a limitation of the ipsec service, but it is worth looking at even if it is an edge case.

The only thing that could present a difference here is the hardware crypto in the safexcel driver. But you said you tried using a cipher that does not effect (blowfish) so it can't be that directly.

So I'm left trying to think of something you might have had set in the old device that's somehow incompatible with the SG-1100. I can't see what that could be though.

The fact setting the tunnel to use ports 600/4600 allowed it to come up implies something in the path blocking the standard ports. The crypto hardware doesn't care what ports are in use for example.

It really 'feels' like the upstream device trying to do something clever with IPSec traffic.

Are we able to review the config you are importing to the 1100? If you open a ticket with us and reference this thread the guys will make sure I see it.

It's hard to see how this could be a hardware issue. If we swapped it out I would expect another device to do exactly the same thing given the same config.

Steve

@djohnson
This is a late reply but it may assist someone else in future.
The VOIP audio traffic (RTP) require separate UDP ports to be open. The exact range will vary depending on your VoIP system.

Hence, if the RTP ports are not open, you can experience a "working" system, but with a complete lack of audio.

Also, this should not be possible, right?

b59dd3a3-ac9d-4c42-89f7-6bf3dbd29f62-image.png

172.17.1.27 is a Server on the IPsec-Side, not an OVPN-client.
Why did this appear as src on the ovpns1 Interface...