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.

Messages - hcso-tm

Pages: [1]

Virtual private networks / problem with redirect gateway

« on: May 21, 2024, 02:21:20 pm »

Hi all,

we have an issue configuring a new vpn server (OpenVPN) without "redirect gateway" but accessing internal services.

what we want to achieve:
1. Client traffic not running over our internet connection, excepted
2. Clients access to DFS-Shares
3. we have conditional forwarding in DNS for access on resources in customer network

when we use the "redirect gateway" option -> 2. and 3. is working
when we set "pull-filter ignore redirect-gateway" on the client -> 1. and 2. is working

is there a way, to get all 3 things running at the same time?

Our setup:

Redirect Gateway = true
Dynamic IP = true
Topology = true
DNS Default Domain = our internal Domain
DNS Servers = our 1st and 2nd DNS-Server IP

within the ovpn-config file on the client we set

pull-filter ignore redirect-gateway

Virtual private networks / OpenVPN DNS trouble

« on: July 03, 2023, 12:18:16 pm »

Hi,
we do have a problem with DNS-Resolution through the tunnel.

The behavior is very strange. We do have the internal Domain mc.local and the Domain mycompany.com

Code: [Select]

nslookup testserver.mc.local 
nslookup testwebsite.mycompany.com

both results in NX-Domain resolved by the dns server where the client resides.

Code: [Select]

nslookup testserver.mc.local 172.16.0.10 #DNS Server at Site, not opnSense
nslookup testwebsite.mycompany.com 172.16.0.10

Both resolves the servers.

The real strange part is:

Code: [Select]

ping testserver.mc.local does work,

Code: [Select]

ping testwebsite.mycompany.comdoes NOT. It does work however, when we add the name resolution in the hosts file.

Our Server Settings are:

Code: [Select]

DNS Default Domain: mc.local
DNS Domain search list: mycompany.com
DNS Servers 172.16.0.10
Force DNS cache update: tested, no difference
Prevent DNS leaks: tested, no difference
redirect gateway: false (when true, it does work)
IPv4 Local Network: 172.16.0.0/16

It behaves the same on all 4 possible connections:

Client:
Windows 10 OpenVPN Connect 3.3.7 (latest Version)
Windows 11 OpenVPN Connect 3.3.7 (latest Version)

Server:
OPNsense 23.1.11-amd64 (OpenVPN 2.6.5)
OPNsense 22.1.6-amd64 (OpenVPN 2.5.6)

We didn´t change the server Config for over one year and nobody complained, so we are pretty sure, it did work up until a few weeks ago.
Since last week, we got three reports, about this issue.

What really puzzles me, is the fact that OpenVPN-Connect had its last update in February and it happens on the old and new OpnSense Version.
The only thing, I can think of, are Windows-Update, that broke something on Win10 and 11...
Or nobody wanted to use those "internal-Only" websites for half a year and last week 3 guys (from 2 different customers, so they are totally independent!) wanted to use it again.

Does anybody have the same issue and/or a solution?

Thanks in advance
Jochen

Tutorials and FAQs / Auto-Updating Alias for Microsoft O365 Endpoints

« on: July 25, 2022, 05:56:00 pm »

Hi,
I wrote a little PHP script to create an Alias-parsable list of IP-Addresses.

https://github.com/JochenKorge/m365enpoints

Its my very first php-Script, so reviewing is recommended

Pull requests for other sources (or IPv6) are welcome.

Cheers Jochen

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: May 02, 2022, 07:32:50 pm »

Finally solved it:

You need to configure the Local and Remote Network in "Client Specific Overrides" on the Server-Side.
Settings made in the Server-Settings are ignored...

Please Update the Documentation to make that clear! Is there any reason to have those Options in Server-Settings? Is there any Case where they work?

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 29, 2022, 02:51:22 pm »

After some further testing (included HW and IP-Changes) I found those lines in OpenVPN Debug11 Logs:

Code: [Select]

2022-04-29T14:39:44	openvpn[52367]	test_pcsm/XXX.XXX.XXX.XXX:49277 MULTI: bad source address from client [192.168.78.76], packet dropped
2022-04-29T14:39:44	openvpn[52367]	test_pcsm/XXX.XXX.XXX.XXX:49277 GET INST BY VIRT: 192.168.78.76 [failed]

=> seems like broken Routing

route get 192.168.78.76 tells me the correct route...

Is it possible, that OpenVPN does not use the OS-Routingtable?

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 28, 2022, 01:52:01 pm »

I did rebuild the complete Tunnel, still the same behavior $:-\$

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 28, 2022, 11:32:17 am »

Yes, I followed that documentation.

I did just capture the WAN-Interface too and realized, that those missing packets don´t reach the WAN (even though you see them "leaving" in the tunnel-interface dump). Successful pings do correlate to WAN-Packets

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 28, 2022, 10:38:14 am »

From main to branch nothing happens, I see Packets going out on Tunnel@MainFW, nothing arriving at Tunnel@branch (see attachments from this post).
tcp-Dumps from branch to main are in the first post.

It is really strange...

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 27, 2022, 05:47:53 pm »

Yeah, that was my first guess, but it seems not to be the case

Routes on Server

Code: (Routes on Server) [Select]

   route to: 172.24.240.1
destination: 172.24.240.1
        fib: 0
  interface: lo0
      flags: <UP,HOST,DONE,STATIC,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0 
   route to: 172.24.240.2
destination: 172.24.240.2
        fib: 0
  interface: ovpns3
      flags: <UP,HOST,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0 
   route to: 172.24.0.1
destination: 172.24.0.1
        fib: 0
  interface: lo0
      flags: <UP,HOST,DONE,STATIC,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0 
   route to: 172.26.0.1
destination: 172.26.0.0
       mask: 255.255.0.0
    gateway: 172.24.240.2
        fib: 0
  interface: ovpns3
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

Code: ( Routes on Client) [Select]

   route to: 172.24.240.1
destination: 172.24.240.1
        fib: 0
  interface: ovpnc1
      flags: <UP,HOST,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0 
   route to: 172.24.240.2
destination: 172.24.240.2
        fib: 0
  interface: lo0
      flags: <UP,HOST,DONE,STATIC,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0 
   route to: 172.24.0.1
destination: 172.24.0.0
       mask: 255.254.0.0
    gateway: 172.24.240.1
        fib: 0
  interface: ovpnc1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0 
   route to: 172.26.0.1
destination: 172.26.0.1
        fib: 0
  interface: lo0
      flags: <UP,HOST,DONE,STATIC,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0

Code: (all routes Server) [Select]

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            XXX.XXX.XXX.XXX    UGS      vtnet1

...

127.0.0.1          link#5             UH          lo0
172.24.0.0/24      link#16            U      vtnet0_v
172.24.0.0/22      link#16            U      vtnet0_v
172.24.0.1         link#16            UHS         lo0
172.24.0.2         link#16            UHS         lo0
172.24.8.0/24      link#10            U      vtnet0_v
172.24.8.1         link#10            UHS         lo0
172.24.8.2         link#10            UHS         lo0
172.24.12.0/24     link#11            U      vtnet0_v
172.24.12.1        link#11            UHS         lo0
172.24.12.2        link#11            UHS         lo0
172.24.16.0/24     link#15            U      vtnet0_v
172.24.16.1        link#15            UHS         lo0
172.24.16.2        link#15            UHS         lo0
172.24.20.0/24     link#17            U      vtnet0_v
172.24.20.1        link#17            UHS         lo0
172.24.20.2        link#17            UHS         lo0
172.24.24.0/24     link#18            U      vtnet0_v
172.24.24.1        link#18            UHS         lo0
172.24.24.2        link#18            UHS         lo0
172.24.28.0/24     link#14            U      vtnet0_v
172.24.28.1        link#14            UHS         lo0
172.24.28.2        link#14            UHS         lo0
172.24.32.0/24     link#41            U      vtnet0_v
172.24.32.1        link#41            UHS         lo0
172.24.32.2        link#41            UHS         lo0
172.24.240.0/24    172.24.240.2       UGS      ovpns3
172.24.240.1       link#12            UHS         lo0
172.24.240.2       link#12            UH       ovpns3
172.24.248.0/24    link#3             U        vtnet2
172.24.248.2       link#3             UHS         lo0
172.25.0.0/22      link#20            U      vtnet0_v
172.25.0.1         link#20            UHS         lo0
172.25.0.2         link#20            UHS         lo0
172.25.4.0/22      link#21            U      vtnet0_v
172.25.4.1         link#21            UHS         lo0
172.25.4.2         link#21            UHS         lo0
172.25.8.0/22      link#22            U      vtnet0_v
172.25.8.1         link#22            UHS         lo0
172.25.8.2         link#22            UHS         lo0
172.25.12.0/22     link#23            U      vtnet0_v
172.25.12.1        link#23            UHS         lo0
172.25.12.2        link#23            UHS         lo0
172.25.16.0/22     link#24            U      vtnet0_v
172.25.16.1        link#24            UHS         lo0
172.25.16.2        link#24            UHS         lo0
172.25.20.0/22     link#25            U      vtnet0_v
172.25.20.1        link#25            UHS         lo0
172.25.20.2        link#25            UHS         lo0
172.25.24.0/22     link#26            U      vtnet0_v
172.25.24.1        link#26            UHS         lo0
172.25.24.2        link#26            UHS         lo0
172.25.28.0/22     link#27            U      vtnet0_v
172.25.28.1        link#27            UHS         lo0
172.25.28.2        link#27            UHS         lo0
172.25.32.0/22     link#28            U      vtnet0_v
172.25.32.1        link#28            UHS         lo0
172.25.32.2        link#28            UHS         lo0
172.25.36.0/22     link#29            U      vtnet0_v
172.25.36.1        link#29            UHS         lo0
172.25.36.2        link#29            UHS         lo0
172.25.40.0/22     link#30            U      vtnet0_v
172.25.40.1        link#30            UHS         lo0
172.25.40.2        link#30            UHS         lo0
172.25.44.0/22     link#31            U      vtnet0_v
172.25.44.1        link#31            UHS         lo0
172.25.44.2        link#31            UHS         lo0
172.25.48.0/22     link#32            U      vtnet0_v
172.25.48.1        link#32            UHS         lo0
172.25.48.2        link#32            UHS         lo0
172.25.52.0/22     link#42            U      vtnet0_v
172.25.52.1        link#42            UHS         lo0
172.25.52.2        link#42            UHS         lo0
172.25.56.0/22     link#8             U      vtnet0_v
172.25.56.1        link#8             UHS         lo0
172.25.56.2        link#8             UHS         lo0
172.25.128.0/24    link#38            U      vtnet0_v
172.25.128.1       link#38            UHS         lo0
172.25.128.2       link#38            UHS         lo0
172.25.232.0/22    link#33            U      vtnet0_v
172.25.232.1       link#33            UHS         lo0
172.25.232.2       link#33            UHS         lo0
172.25.236.0/22    link#34            U      vtnet0_v
172.25.236.1       link#34            UHS         lo0
172.25.236.2       link#34            UHS         lo0
172.25.240.0/22    link#35            U      vtnet0_v
172.25.240.1       link#35            UHS         lo0
172.25.240.2       link#35            UHS         lo0
172.25.244.0/22    link#36            U      vtnet0_v
172.25.244.1       link#36            UHS         lo0
172.25.244.2       link#36            UHS         lo0
172.25.248.0/22    link#37            U      vtnet0_v
172.25.248.1       link#37            UHS         lo0
172.25.248.2       link#37            UHS         lo0
172.25.252.0/24    172.25.252.2       UGS      ovpns2
172.25.252.1       link#40            UHS         lo0
172.25.252.2       link#40            UH       ovpns2
172.25.253.0/24    172.25.253.2       UGS      ovpns1
172.25.253.1       link#39            UHS         lo0
172.25.253.2       link#39            UH       ovpns1
172.26.0.0/16      172.24.240.2       UGS      ovpns3

Code: (all routes client) [Select]

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.26.124.20      UGS      vtnet1
127.0.0.1          link#5             UH          lo0
172.24.0.0/15      172.24.240.1       UGS      ovpnc1
172.24.240.0/24    172.24.240.1       UGS      ovpnc1
172.24.240.1       link#11            UH       ovpnc1
172.24.240.2       link#11            UHS         lo0
172.26.0.0/22      link#9             U      vtnet0_v
172.26.0.1         link#9             UHS         lo0
172.26.0.2         link#9             UHS         lo0
172.26.8.0/24      link#10            U      vtnet0_v
172.26.8.1         link#10            UHS         lo0
172.26.8.2         link#10            UHS         lo0
172.26.12.0/24     link#12            U      vtnet0_v
172.26.12.1        link#12            UHS         lo0
172.26.12.2        link#12            UHS         lo0
172.26.120.0/24    link#3             U        vtnet2
172.26.120.2       link#3             UHS         lo0
172.26.124.0/24    link#2             U        vtnet1
172.26.124.1       link#2             UHS         lo0
172.26.124.2       link#2             UHS         lo0
192.168.78.0/24    link#4             U        vtnet3
192.168.78.2       link#4             UHS      vtnet3
192.168.78.81      link#4             UHS         lo0

Internet6:
...

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 27, 2022, 03:33:59 pm »

For testing purposes something like:
Allow Any * * * *
on both Firewalls

I do see the Rule on the Branch-Office Firewall-Log and nothing on Main-Net, but again:
Packet capture shows outgoing traffic that gets lost somewhere in the tunnel while the tunnel itself stays up... That is the strange part.

BTW: the other way round (Ping from Main-Net to Branch) does only work on the Tunnel-IP. Any other IP is unreachable and no packets are captured on the Branch Firewall

Virtual private networks / Re: Site2Site openvpn Tunnel OK, Clients not

« on: April 27, 2022, 02:25:23 pm »

Hi,
we´re currently preparing the first branch-office.

The Main-Site is hosting 2 OPNsenses in HA. Currently running 3 OpenVPN-Servers on different public IP-Adresses.
Server-Mode is P2P ssl/tls
Device Mode tun

Tunnel-Settings:
Tunnel-Network: 172.24.240.0/24 (172.24.240.1 Server in Main-Net, 172.24.240.2 Client in Branch Office)
Redirect Gateway false
Local Network 172.24.0.0/15
Remote Network 172.26.0.0/16
Compression off
Type of Service false
Duplicate Connections true (tested with false too)

Client Settings:
Dynamic IP true
Address Pool true
Topology true
Client Management Port false

No Advanced config

It is Route-Based and those Routes were automatically created in the Routing table.
Our Main-Net is 172.24.0.0/15 (172.24.0.0/16 for Server/Infrastructure and 172.25.0.0/16 for Clients)
Branch-Office will be 172.26.0.0/16 (172.26.0.0/17 for Server/Infrastructure and 172.26.128.0/17 for Clients)

As I mentioned: Routing and the Tunnel itself seems to work. I see the packages in the Firewall logs leaving the FW on the Tunnel-Interface, I see them on the Packet-Capture on the Tunnel, I just miss them arriving on the Tunnel Interface on the Server.

I just tried to connect to a Service in Main net: From the Firewall in the Branch-Office it works, from the Client it doesn´t (same as connecting to the OpenVPN Server itself)

Virtual private networks / [SOLVED]Site2Site openvpn Tunnel OK, Clients not

« on: April 27, 2022, 01:12:33 pm »

Hi,

I did encounter some really strange behavior.
We did Setup a OpenVPN Tunnel between 2 Opensense FWs. The Tunnel seems to be fine. When I Ping/Portprobe "ServerFW" from "ClientFW" it just works as expected.
When I try the same from a PC connected to "ClientFW" I can capture Packages leaving ClientFW, not arriving at ServerFW.

First, i tried nc from a pc connected to ClientFW. You can see that the ClientFW tried to send those Packages to ServerFW. On the Server-Side there is nothing captured.
After that, I used the Interface->Debuging->Port-Probe on the ClientFW. Those Packages are captured at both ends.

See attached Captures.
Capture Setting on both firewalls are set to: Tunnel Interface, promiscuos Mode, TCP Port 443, started at the same Time.

Any ideas why traffic in the Tunnel is behaving so strange?

High availability / HA/CARP, routed subnets and needed IPs

« on: October 26, 2021, 03:15:36 pm »

Hi,
I´m trying to wrap my Head around the possible configurations of CARP on our WAN side.

Our Addresses are:
XX.XX.212.243/31 OPNSense WAN (Gateway XX.XX.212.242)
Additionally our Provider routes two /29 Subnets to XX.XX.212.243
XX.XX.212.248/29
XX.XX.237.192/29

Were able to use all 16 Adresses from the /29 Nets as Client or VirtualIPs.

I do see two options:
1) we need to 1:1 NAT our main Address onto another Address like 10.0.0.1, used as CAPR-VIP, add 2 "normal" Wan Interfaces 10.0.0.2 and 10.0.0.3 and use XX.XX.212.242 as Far Gateway
2) we ask our Provider to move the allocation like so:
XX.XX.212.248/29 as our "main" Subnet
XX.XX.212.249 Gateway
XX.XX.212.250 CAPR-VIP<- XX.XX.237.192/29 and XX.XX.212.242/31 routed there
XX.XX.212.251 WAN FW1
XX.XX.212.252 WAN FW2
XX.XX.212.253 & 254 Usable as Client or "normal" Virtual IP

Is there a third option? I dislike the additional NAT (mainly because we need a Site to Site IPSec tunnel which dislikes NAT) and Option 2 sounds like a lot of work.

Thanks in Advanced

Pages: [1]