Automatically routed to ISP router Private IP if a client VPN is active
-
@giuliolinux said in Automatically routed to ISP router Private IP if a client VPN is active:
A couple of questions arise:
why and through which protocol does the WAN (or the OpenVPN client) communicate with a private IP of the provider's router if present, even though no PfSense interface has an IP on that net? (ex: 192.168.1.0/24).
I assume, the ISP router is the default gateway on pfSense. So pfSense routes any destination IPs to it, which it has no other route for.
What would be the "cleanest" solution to solve this problem given that regardless of the private IP of the provider's router, there is a route to that destination?
The "cleanest" way would be to assign an IP within the routers subnet to the WAN interface and add an outbound NAT rule for the destination IP of the routers and set it to "no NAT". But obviously this is not really necessary for your ISP router, since it also works with the WAN IP.
Anyway you have to add the route for the IP to the OpenVPN settings. In the OpenVPN server you can add its IP in CIDR notation to the "Local Networks" to push the route to the clients.
This cannot be done regardless the the routers IP of course, and why will you have it this way?Also you might have to add an outbound NAT rule for the source of the OpenVPN tunnel network and set the translation to "WAN address".
-
@viragomann said in Automatically routed to ISP router Private IP if a client VPN is active:
@giuliolinux said in Automatically routed to ISP router Private IP if a client VPN is active:
I assume, the ISP router is the default gateway on pfSense. So pfSense routes any destination IPs to it, which it has no other route for.
yeah, sure...
The "cleanest" way would be to assign an IP within the routers subnet to the WAN interface and add an outbound NAT rule for the destination IP of the routers and set it to "no NAT". But obviously this is not really necessary for your ISP router, since it also works with the WAN IP.
Anyway you have to add the route for the IP to the OpenVPN settings. In the OpenVPN server you can add its IP in CIDR notation to the "Local Networks" to push the route to the clients.
This cannot be done regardless the the routers IP of course, and why will you have it this way?Also you might have to add an outbound NAT rule for the source of the OpenVPN tunnel network and set the translation to "WAN address".
OK, I will try. I will also try asking the provider to exclude this route from their router / default gateway.
Many thanks for your support and your time!
-
@giuliolinux said in Automatically routed to ISP router Private IP if a client VPN is active:
I will also try asking the provider to exclude this route from their router / default gateway.
Which route do you mean?
-
... I mean to remove the 192.168.1.0/24 from their routes on the perimetral router of the ISP.
Regards
-
@giuliolinux
The router has an IP in the 192.168.1.0/24 subnet, and hence he also has a route for this.
The IP is meant to give you access to it. Without the route that won't be possible. -
Hi,
I think there is a misunderstanding. Our WAN has a default gateway on a public subnet. This link allows us to apply virtual IPs on pfsense to manage the 64 Public IPs that the ISP provides us and then the various internal networks are routed externally via the outbound specifications that use some of the 64 Public IPs. None of our internal networks use the 192.168.1.0/24 subnet, and these routes are not present even in the VPNs we establish to our customers' destinations. So I assume that the public route on the ISP's p2p routes us to its device (basically we have no hops with a traceroute) ...
-
-
@giuliolinux
It's the next device to WAN directly linked to pfSense. I don't expect to see a hop to this IP.And there might also be no route.
I assume the ISP router as a public IP as well and this is used on pfSense as upstream gateway.
So since your pfSense doesn't know any other route for 192.168.1.1, it will send requests to this destination to the gateway IP, which is the same device. So the router will respond to that.Same on your pfSense. You say, you have multiple internal networks. So you can go to a device in subnet A and call the subnet B IP of pfSense. Presumed the firewall rules on A allows it, pfSense will respond normally.
-
Hi,
I try to explain better below. Configuring our WAN:
WAN address (point to point of the ISP):
IP: 89.2**.2**.78
Def-GW: 89.2**.2**.77As I wrote above through the ISP's p2p connection we can use 64 IPs (Virtual IPs with Proxy Arp). This allows us to set outbound and inbound access to services. Let's say that I will describe this last aspect to you but it is not important in the evaluation of the subject matter.
Pfsense routing - as shown below - means that there is no interface set up on the 192.168.1.1 network (it is an ISP device since we only hop from pfsense to that IP).
default 89.2**.2**.77 UGS 686922 1500 bce1
1.0.0.1 10.128.0.1 UGHS 10625481 1500 em3
1.1.1.1 89.212.25.77 UGHS 10624184 1500 bce1
8.8.8.8 77.94.136.193 UGHS 10624818 1500 bce0
10.0.0.0/24 10.10.82.1 UGS 1 1500 ovpnc35
10.0.1.0/28 link#11 U 24068685 1500 em2.100
10.0.1.14 link#11 UHS 0 16384 lo0
10.0.1.16/28 link#12 U 24371836 1500 em2.101
10.0.1.30 link#12 UHS 0 16384 lo0
10.0.1.32/28 link#13 U 0 1500 em2.102
10.0.1.46 link#13 UHS 0 16384 lo0
10.0.1.48/28 link#14 U 0 1500 em2.103
10.0.1.62 link#14 UHS 0 16384 lo0
10.0.1.64/28 link#15 U 14864827 1500 em2.104
10.0.1.78 link#15 UHS 0 16384 lo0
10.0.1.80/28 link#16 U 87763530 1500 em2.105
10.0.1.94 link#16 UHS 0 16384 lo0
10.0.1.96/28 link#17 U 0 1500 em2.106
10.0.1.110 link#17 UHS 0 16384 lo0
10.0.1.112/28 link#18 U 0 1500 em2.107
10.0.1.126 link#18 UHS 0 16384 lo0
10.0.1.128/28 link#19 U 13693489 1500 em2.108
10.0.1.142 link#19 UHS 0 16384 lo0
10.0.1.144/28 link#20 U 747606 1500 em2.109
10.0.1.158 link#20 UHS 0 16384 lo0
10.0.1.160/28 link#21 U 15640132 1500 em2.110
10.0.1.174 link#21 UHS 0 16384 lo0
10.0.1.176/28 link#22 U 10033377 1500 em2.111
10.0.1.190 link#22 UHS 0 16384 lo0
10.0.1.192/28 link#23 U 11 1500 em2.112
10.0.1.206 link#23 UHS 0 16384 lo0
10.0.1.208/28 link#24 U 0 1500 em2.113
10.0.1.222 link#24 UHS 0 16384 lo0
10.0.1.224/28 link#25 U 0 1500 em2.114
10.0.1.238 link#25 UHS 0 16384 lo0
10.0.1.240/28 link#26 U 0 1500 em2.115
10.0.1.254 link#26 UHS 0 16384 lo0
10.0.2.0/28 link#27 U 0 1500 em2.116
10.0.2.14 link#27 UHS 0 16384 lo0
10.0.2.16/28 link#28 U 0 1500 em2.117
10.0.2.30 link#28 UHS 0 16384 lo0
10.0.2.32/28 link#29 U 0 1500 em2.118
10.0.2.46 link#29 UHS 0 16384 lo0
10.0.2.48/28 link#30 U 0 1500 em2.119
10.0.2.62 link#30 UHS 0 16384 lo0
10.0.2.64/28 link#31 U 0 1500 em2.120
10.0.2.78 link#31 UHS 0 16384 lo0
10.0.2.80/28 link#32 U 0 1500 em2.121
10.0.2.94 link#32 UHS 0 16384 lo0
10.0.2.96/28 link#33 U 0 1500 em2.122
10.0.2.110 link#33 UHS 0 16384 lo0
10.0.2.112/28 link#34 U 0 1500 em2.123
10.0.2.126 link#34 UHS 0 16384 lo0
10.0.2.128/28 link#35 U 0 1500 em2.124
10.0.2.142 link#35 UHS 0 16384 lo0
10.0.2.144/28 link#36 U 0 1500 em2.125
10.0.2.158 link#36 UHS 0 16384 lo0
10.0.2.160/28 link#37 U 0 1500 em2.126
10.0.2.174 link#37 UHS 0 16384 lo0
10.0.2.176/28 link#38 U 0 1500 em2.127
10.0.2.190 link#38 UHS 0 16384 lo0
10.0.2.192/28 link#39 U 0 1500 em2.128
10.0.2.206 link#39 UHS 0 16384 lo0
10.0.2.208/28 link#40 U 0 1500 em2.129
10.0.2.222 link#40 UHS 0 16384 lo0
10.0.2.224/28 link#41 U 0 1500 em2.130
10.0.2.238 link#41 UHS 0 16384 lo0
10.0.2.240/28 link#42 U 0 1500 em2.131
10.0.2.254 link#42 UHS 0 16384 lo0
10.0.3.0/29 link#43 U 3877802 1500 em2.132
10.0.3.6 link#43 UHS 0 16384 lo0
10.0.3.8/29 link#44 U 3939412 1500 em2.133
10.0.3.14 link#44 UHS 0 16384 lo0
10.0.3.16/29 link#45 U 15005758 1500 em2.134
10.0.3.22 link#45 UHS 0 16384 lo0
10.0.3.24/29 link#46 U 325012 1500 em2.135
10.0.3.30 link#46 UHS 0 16384 lo0
10.0.3.32/29 link#47 U 4456046 1500 em2.136
10.0.3.38 link#47 UHS 0 16384 lo0
10.0.3.40/29 link#48 U 2932343 1500 em2.137
10.0.3.46 link#48 UHS 0 16384 lo0
10.0.3.48/29 link#49 U 2125567 1500 em2.138
10.0.3.54 link#49 UHS 0 16384 lo0
10.0.3.56/29 link#50 U 1633429 1500 em2.139
10.0.3.62 link#50 UHS 0 16384 lo0
10.0.3.64/29 link#51 U 1556704 1500 em2.140
10.0.3.70 link#51 UHS 0 16384 lo0
10.0.3.72/29 link#52 U 792059 1500 em2.141
10.0.3.78 link#52 UHS 0 16384 lo0
10.0.3.80/29 link#53 U 1133122 1500 em2.142
10.0.3.86 link#53 UHS 0 16384 lo0
10.0.3.88/29 link#54 U 0 1500 em2.143
10.0.3.94 link#54 UHS 0 16384 lo0
10.0.3.96/29 link#55 U 2615458 1500 em2.144
10.0.3.102 link#55 UHS 0 16384 lo0
10.0.3.104/29 link#56 U 0 1500 em2.145
10.0.3.110 link#56 UHS 0 16384 lo0
10.0.3.112/29 link#57 U 0 1500 em2.146
10.0.3.118 link#57 UHS 0 16384 lo0
10.0.3.120/29 link#58 U 0 1500 em2.147Thanks for your help.
-
yesss, all clear. My problem is that I have a new customer that have a LAN network 192.168.1.0/24 that I will have to reach from Pfsense - and our networks above -
So I hope that the ISP router does not intercept them, but that I will reach that network via Ovpn Client.
Regards
-
@giuliolinux said in Automatically routed to ISP router Private IP if a client VPN is active:
My problem is that I have a new customer that have a LAN network 192.168.1.0/24 that I will have to reach from Pfsense
That's the thing I was missing before.
I guess, the customer is connected via an OpenVPN site-to-site. So add 192.168.1.0/24 to the "Remote Networks" in your pfSense VPN settings.
There is nothing, the ISP can do for achieve access to this customer.
As said, if pfSense has no other route it directs destination IPs to the default gateway. -
Ok,
thanks for your precious help, and in any case sorry for my approx english ;P
Ciao (form Italy)