1
General Discussion / Re: OpenVPN and NAT Reflection
« on: December 11, 2018, 11:25:07 am »
No takers?
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.
Pages: [1] 2
2
General Discussion / OpenVPN and NAT Reflection
« on: November 20, 2018, 11:04:22 am »
Hi all,
Back after dropping OPNSense and going to Pfsense due to being unable to fix some VPN and load balancing issues. The last version of OPNSense I used was 16.7, and it appears most of the issues I experienced before are now fixed.
Hoping to try the traffic shaper later today (Pfsense's non-sensical HFSC shaper drove me mad, it simply doesn't work!). Now using 18.7.
I've cloned most of my Pfsense settings including my three OpenVPN servers (two peer to peer and one roadwarrior) and I'm finding my RW clients won't connect from inside the LAN, where they did on Pfsense. Any ideas? My thoughts were that it was something to do with NAT Reflection as my clients are configured to connect to the WAN address but I've tried all the options for that and can't get it to work. Besides, the same options were off on Pfsense and it worked out of the box!
I could get around this by using split DNS but I'd have to reconfigure my clients to use the DNS record rather than the IP.
I have the VPN sever listening on all interfaces.
Thanks!
Back after dropping OPNSense and going to Pfsense due to being unable to fix some VPN and load balancing issues. The last version of OPNSense I used was 16.7, and it appears most of the issues I experienced before are now fixed.
Hoping to try the traffic shaper later today (Pfsense's non-sensical HFSC shaper drove me mad, it simply doesn't work!). Now using 18.7.
I've cloned most of my Pfsense settings including my three OpenVPN servers (two peer to peer and one roadwarrior) and I'm finding my RW clients won't connect from inside the LAN, where they did on Pfsense. Any ideas? My thoughts were that it was something to do with NAT Reflection as my clients are configured to connect to the WAN address but I've tried all the options for that and can't get it to work. Besides, the same options were off on Pfsense and it worked out of the box!
I could get around this by using split DNS but I'd have to reconfigure my clients to use the DNS record rather than the IP.
I have the VPN sever listening on all interfaces.
Thanks!
3
16.7 Legacy Series / Re: Sticky Connections Broken
« on: October 18, 2016, 05:27:58 pm »
Sorry for the late reply - turned out to be something else entirely.
We do seem to have some other weird problems with gateways though.
If a gateway's status is shown as 'Unknown' (like after first boot), I have to manually restart the apinger service to get a proper status to show (It's been an issue over several versions of opnsense and on several pieces of hardware). The behaviour we've noticed is that on a multi-wan setup this makes the connection with 'Unknown' status get ignored within a gateway group until the next restart of the apinger service. This doesn't allow our box to run autonomously i.e. if we have a power or intermittent line failure someone has to log into opnsense and keep restarting the apinger service to make sure we have 'online' status at all times, effectively making it a manual failover.
Also when we started investigating the problem further we discovered that if we disable all gateways and reboot opnsense the gateways show as disabled but they remain enabled (i.e. traffic still flows like we didn't disable them); this can't be right. It's as though the gateway group feature undermines the individual gateway's 'disabled' status. If this is intentional behaviour, is it possible to have an option to disable the group?
Are these known issues?
We do seem to have some other weird problems with gateways though.
If a gateway's status is shown as 'Unknown' (like after first boot), I have to manually restart the apinger service to get a proper status to show (It's been an issue over several versions of opnsense and on several pieces of hardware). The behaviour we've noticed is that on a multi-wan setup this makes the connection with 'Unknown' status get ignored within a gateway group until the next restart of the apinger service. This doesn't allow our box to run autonomously i.e. if we have a power or intermittent line failure someone has to log into opnsense and keep restarting the apinger service to make sure we have 'online' status at all times, effectively making it a manual failover.
Also when we started investigating the problem further we discovered that if we disable all gateways and reboot opnsense the gateways show as disabled but they remain enabled (i.e. traffic still flows like we didn't disable them); this can't be right. It's as though the gateway group feature undermines the individual gateway's 'disabled' status. If this is intentional behaviour, is it possible to have an option to disable the group?
Are these known issues?
4
16.7 Legacy Series / Sticky Connections Broken
« on: September 27, 2016, 10:10:19 am »
Currently running 16.7.4 - prior to this sticky connections worked fine but now it seems to be broken - users logging in to websites keep getting logged out, which is the behaviour we experienced before turning on sticky connections. To try and get around I have a firewall rule for LAN set to route all 443 traffic through WAN1 which works for some websites but not others.
5
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: September 14, 2016, 01:42:20 pm »
Any closer on this?
Thanks!
Thanks!
6
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: September 05, 2016, 12:34:49 pm »
Apologies for letting a thread I started slowly die - been away on hols!
Many thanks for your help on this; looking forward to a fix.
Many thanks for your help on this; looking forward to a fix.
7
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: August 18, 2016, 12:09:27 pm »
No - the wizard doesn't appear to do shared key peer-peer connections.
I followed the guide on the Wiki, which didn't work as my server side is on a multi-wan (to get around this I had to put a rule above the default lan to any rule to point any traffic for remote networks (10.0.2.0/23 and 10.0.4.0/23) to the 'default' gateway and not the gateway group.
NAT outbound rules are on auto, this config worked fine with above firewall rules with one server, just not two. Also if I have a problem with NAT rules, surely my client should be able to ping in?
I followed the guide on the Wiki, which didn't work as my server side is on a multi-wan (to get around this I had to put a rule above the default lan to any rule to point any traffic for remote networks (10.0.2.0/23 and 10.0.4.0/23) to the 'default' gateway and not the gateway group.
NAT outbound rules are on auto, this config worked fine with above firewall rules with one server, just not two. Also if I have a problem with NAT rules, surely my client should be able to ping in?
8
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: August 18, 2016, 11:11:42 am »
Yup,
1195 allowed on firewall for WAN (VPN connection showing UP).
I don't allow any to any on the OpenVPN tab though, I have two rules server side, one to allow from 10.0.4.0/23 and one to allow from 10.0.2.0/23, which are my remote networks as configured in the servers.
OpenVPN rules on both client sides are to allow traffic from 10.0.0.0/23, first VPN server & client works great, second shows UP but doesn't let any traffic flow in any direction.
Tracert from server side LAN machine to client at the non-working site reveals that the pinging is going down the wrong tunnel, i.e. 10.1.0.0/24 instead of 10.2.0.0/24.
Thanks.
1195 allowed on firewall for WAN (VPN connection showing UP).
I don't allow any to any on the OpenVPN tab though, I have two rules server side, one to allow from 10.0.4.0/23 and one to allow from 10.0.2.0/23, which are my remote networks as configured in the servers.
OpenVPN rules on both client sides are to allow traffic from 10.0.0.0/23, first VPN server & client works great, second shows UP but doesn't let any traffic flow in any direction.
Tracert from server side LAN machine to client at the non-working site reveals that the pinging is going down the wrong tunnel, i.e. 10.1.0.0/24 instead of 10.2.0.0/24.
Thanks.
9
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: August 18, 2016, 10:07:23 am »
Just double-checked, there's definitely some sort of problem with this; I removed and re-added my client and the OpenVPN tab disappeared on the firewall rules as expected, but it didn't reappear. I had to reboot.
Also, I can't for the life of me get the second tunnel to work; the connection shows as 'up', but I can't get anything to ping either way. Definitely broken on a second tunnel!
Also, I can't for the life of me get the second tunnel to work; the connection shows as 'up', but I can't get anything to ping either way. Definitely broken on a second tunnel!
10
16.7 Legacy Series / Re: OpenVPN - Possible Bug with Multiple Servers
« on: August 17, 2016, 10:25:59 pm »
Are you sure? I've seen two before when I've added a second server during testing, I though this was the norm.
11
16.7 Legacy Series / OpenVPN - Possible Bug with Multiple Servers
« on: August 17, 2016, 04:11:50 pm »
Just tried to add a second client to a peer to peer VPN connection and found that the server can't handle two connections at once, so to get around this added a second server on port 1195.
Problem is a new tab on the firewall rules doesn't appear for the new second OpenVPN interface so can't add any rules; any ideas?
Thanks.
Problem is a new tab on the firewall rules doesn't appear for the new second OpenVPN interface so can't add any rules; any ideas?
Thanks.
12
16.7 Legacy Series / Re: Multi Wan and OpenVPN
« on: August 11, 2016, 10:16:55 am »
Hi franco,
Not sure what that means (sorry).
I've actually got it working now. The multi WAN is set up using a gateway group, two FTTC conections Tier 1 and a 4G LTE connection as a Tier 2 backup. The default LAN to any rule has the gateway group set.
I think there may be a bug though; I added a new rule above the default LAN to any rule and set any traffic heading to 10.0.2.0/23 to be sent through WAN1, which is where the VPN server listens. This didn't work. I found the only configuration that made this rule work was to leave the gateway as 'default' in the rule and then set WAN1 as my default gateway. This also meant I had to disable 'Allow default gateway switching' in the system settings.
Thanks.
Not sure what that means (sorry).
I've actually got it working now. The multi WAN is set up using a gateway group, two FTTC conections Tier 1 and a 4G LTE connection as a Tier 2 backup. The default LAN to any rule has the gateway group set.
I think there may be a bug though; I added a new rule above the default LAN to any rule and set any traffic heading to 10.0.2.0/23 to be sent through WAN1, which is where the VPN server listens. This didn't work. I found the only configuration that made this rule work was to leave the gateway as 'default' in the rule and then set WAN1 as my default gateway. This also meant I had to disable 'Allow default gateway switching' in the system settings.
Thanks.
13
16.7 Legacy Series / Multi Wan and OpenVPN
« on: August 10, 2016, 03:23:17 pm »
Hi,
Pretty new to firewalls this advanced and struggling a bit!
Struggling with OpenVPN site-to-site and multi-wan, as follows:
Site A has multi-WAN (two lines load balance and one failover) and static IP's on both WANs. OpenVPN is configured to use WAN1 interface (tun, shared key peer to peer). LAN is on subnet 10.0.0.0/23, server IP 10.0.0.1 and OpnSense box 10.0.0.2. OpenVPN virtual adapter 10.1.0.1.
Site B has single WAN with dynamic IP and is running the OpenVPN client. Connection is up and remains solid. LAN is on subnet 10.0.2.0/23, server IP 10.0.2.1 and OpnSense box 10.0.2.2, OpenVPN virtual adapter 10.1.0.2.
OpenVPN is configured to use 10.1.0.0/24 as the tunnel network.
I have two Windows servers, one at each site. The one client side works great. The Site B server can ping the Site A server and replicate as necessary. A tracert shows correctly, first hop 10.0.2.2, next hop tunnel exit 10.1.0.1 and finally to 10.0.0.1. I can ping both sides of the tunnel also (10.1.0.1 and 10.1.0.2).
If I try to ping back at Site B from Site A though, I get nothing. I can't even ping the local end of the tunnel (10.1.0.1).
I'm thinking there's a NAT rule I have to create on Site A's OpnSense to make sure traffic for the 10.0.2.0/23 network goes through the tunnel and not just out into the abyss over the gateway group, but as I said, new to this sort of thing so not sure how to go about it.
EDIT: Defnintely some sort of rule needed, pings from 10.0.0.2 to 10.1.0.2 and 10.0.2.1 are successful (using the OpnSense Ping util). Strangely though the OpnSense Traceroute doesn't work. Both the pinger and traceroute utils were set to LAN as the local addresses.
Thanks!
Pretty new to firewalls this advanced and struggling a bit!
Struggling with OpenVPN site-to-site and multi-wan, as follows:
Site A has multi-WAN (two lines load balance and one failover) and static IP's on both WANs. OpenVPN is configured to use WAN1 interface (tun, shared key peer to peer). LAN is on subnet 10.0.0.0/23, server IP 10.0.0.1 and OpnSense box 10.0.0.2. OpenVPN virtual adapter 10.1.0.1.
Site B has single WAN with dynamic IP and is running the OpenVPN client. Connection is up and remains solid. LAN is on subnet 10.0.2.0/23, server IP 10.0.2.1 and OpnSense box 10.0.2.2, OpenVPN virtual adapter 10.1.0.2.
OpenVPN is configured to use 10.1.0.0/24 as the tunnel network.
I have two Windows servers, one at each site. The one client side works great. The Site B server can ping the Site A server and replicate as necessary. A tracert shows correctly, first hop 10.0.2.2, next hop tunnel exit 10.1.0.1 and finally to 10.0.0.1. I can ping both sides of the tunnel also (10.1.0.1 and 10.1.0.2).
If I try to ping back at Site B from Site A though, I get nothing. I can't even ping the local end of the tunnel (10.1.0.1).
I'm thinking there's a NAT rule I have to create on Site A's OpnSense to make sure traffic for the 10.0.2.0/23 network goes through the tunnel and not just out into the abyss over the gateway group, but as I said, new to this sort of thing so not sure how to go about it.
EDIT: Defnintely some sort of rule needed, pings from 10.0.0.2 to 10.1.0.2 and 10.0.2.1 are successful (using the OpnSense Ping util). Strangely though the OpnSense Traceroute doesn't work. Both the pinger and traceroute utils were set to LAN as the local addresses.
Thanks!
14
16.7 Legacy Series / Re: Multi WAN and Failover
« on: August 10, 2016, 02:44:36 pm »
Thanks for the reply, much appreciated. Just what I needed to hear!
I've watched the graphs and it's happening as you describe.
Just out of curiosity, I found something over at pfSense that said it's only possible to load balance a maximum of two WANs. Is this the case with OpnSense?
Thanks again.
I've watched the graphs and it's happening as you describe.
Just out of curiosity, I found something over at pfSense that said it's only possible to load balance a maximum of two WANs. Is this the case with OpnSense?
Thanks again.
15
16.7 Legacy Series / Re: OpenVPN: VPN clients no access to LAN network
« on: August 10, 2016, 02:38:26 pm »
This sounds a bit similar to the issue I'm having, though I'm trying to do a site-site connection. Client-side the network can see and ping everything server side, but server side can't see or ping anything client side.
The weird thing is that I can't even ping the virtual/tunnel addresses from the server side. Ill stick it on its own thread, but I'll also keep watching yours!
The weird thing is that I can't even ping the virtual/tunnel addresses from the server side. Ill stick it on its own thread, but I'll also keep watching yours!
Pages: [1] 2