Cannot access webservers through vpn that are on a different gateway
-
@viragomann yes
Are you able to ping the remote network from the webserver as well?
yes! I think routing is perfect -
What I noticed now is that if I masquerade the remote networks on the central mikrotik behind the lan interface, things works. But honestly I'm not sure that masquerading the remote lan is a good practice.
-
@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
But honestly I'm not sure that masquerading the remote lan is a good practice.
Well that again screams asymmetrical.. You sniffing on the webserver doesn't tell you what gateway it sent it too.
If it doesn't send it back to pfsense, then its not going to work.
If your box your trying to get to is not using pfsense as its gateway, then you have couple of options. You either source nat the traffic so it looks like it came from pfsense IP, or your put a route on the dest box that tells it to use pfsense as the gateway to get back to your remote network..
-
@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
if I masquerade the remote networks on the central mikrotik behind the lan interface, things works.
So the only two reasons for failing without that I can think off are
- the route doesn't work
- the destination server itself blocks the access
Blocking access from outside its own subnet is the default behavior of system firewalls, however, a webserver should be configured to accept access from anywhere. I assume, the server is accessible from the internet.
@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
But honestly I'm not sure that masquerading the remote lan is a good practice.
The only one drawback is that you cannot identify the real source address on the destination device, as long as you do the masquerading only for the remote lan.
-
@viragomann said in Cannot access webservers through vpn that are on a different gateway:
the route doesn't work
Route doesn't work where? You can not put the route on the other gateway... It would have to be on the device your trying to talk to..
For starters if this other gateway is stateful he would not pass on your syn,ack because there is no state for it.. The correct solution if you want to bring this vpn in via pfsense vs your current edge is connect pfsense to your edge router via a transit network - as already mentioned by @viragomann
-
@johnpoz
The route on the destination device itself:@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
Since these devices use another default gateway, they will send out responses to it, not back to the IPSec gateway.
You will have to add static routes to both for the remote network, pointing to the Mikrotik. Have you done that?
yes, I added all the necessary static routes on each device on the network both outward and return, otherwise I would not have had ping or registered extensions or even the tcpdump that I reported. -
The logical answer to this is no he didn't do it correctly..
Because if he did - then it would be working..
-
Yeap, I think so.
-
Did he show us these routes? No
Did he show a sniff on pfsense - where the syn,ack was sent back to pfsense - No
But its work if he source nats - logical conclusion is host routing that he stated he did was not done, or was done wrong.
-
@johnpoz
I'm with you. -
Not sure why anyone would go that route anyway.. Why would you not just connect pfsense via a transit network to your edge router.. If you want to use pfsense for vpn.
Or better yet just replace whatever your using as your edge with pfsense, since clearly its vpn features is lacking that you want, or you would just be doing your vpn there.
Its like people like to cause themselves pain and issues, when there is such an easy solution..
-
@johnpoz as I wrote I can ping, I can see traffic going from the remote side to the webserver and viceversa, and most of all my extensions are registering and I can call and pass all rtp traffic, so this cannot be a routing problem. if I make a traceroute from both sides the routing is what I'm expecting see this:
this is from remote workstation to freepbx(that has pfsense as gw)
C:\Windows\system32>tracert 192.168.25.200 Traccia instradamento verso 192.168.25.200 su un massimo di 30 punti di passaggio 1 <1 ms <1 ms <1 ms 192.168.26.1 //this is the remote mikrotik 2 37 ms 37 ms 37 ms 10.0.25.1 //this is the l2pt server 3 38 ms 37 ms 37 ms 192.168.25.200 //freepbx reached Traccia completata.this is from the freepbx to remote workstation
[root@freepbx ~]# traceroute 192.168.26.20 traceroute to 192.168.26.20 (192.168.26.20), 30 hops max, 60 byte packets 1 192.168.25.62 (192.168.25.62) 0.301 ms 0.244 ms 0.204 ms //this is the central mikrotik router 2 10.0.25.2 (10.0.25.2) 37.522 ms 37.611 ms 37.647 ms //this is the l2pt remote client 3 192.168.26.20 (192.168.26.20) 38.085 ms * * //workstation reachedthis is the routing table on my pfsense you will notice that request to remote network 192.168.26.0/24 are routed through the mikrotik gw 192.168.25.62
default xx.xx.xx.xx UGS 1139654 1492 pppoe0 10.0.25.0/24 192.168.25.62 UGS 1 1500 vtnet1 10.0.40.0/24 10.0.40.2 UGS 49992 1500 ovpns1 10.0.40.1 link#9 UHS 0 16384 lo0 10.0.40.2 link#9 UH 2343778 1500 ovpns1 10.0.90.0/24 10.0.90.2 UGS 0 1500 ovpns2 10.0.90.1 link#10 UHS 0 16384 lo0 10.0.90.2 link#10 UH 0 1500 ovpns2 127.0.0.1 link#3 UH 1244 16384 lo0 192.168.25.0/24 link#2 U 754126 1500 vtnet1 192.168.25.76 link#2 UHS 0 16384 lo0 192.168.26.0/24 192.168.25.62 UGS 90979 1500 vtnet1 192.168.27.0/24 192.168.25.62 UGS 326 1500 vtnet1 195.96.194.18 link#8 UH 39459 1492 pppoe0 195.96.195.62 link#8 UHS 0 16384 lo0and this is the traffic in pfsense when trying to open freepbx webgui from remote workstation
23:40:27.265712 IP 192.168.25.200.80 > 192.168.26.20.50808: tcp 0 23:40:27.265751 IP 192.168.25.200.80 > 192.168.26.20.50809: tcp 0 23:40:27.515697 IP 192.168.25.200.80 > 192.168.26.20.50810: tcp 0 23:40:30.813344 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 733 23:40:30.813388 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 0 23:40:30.814584 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 733 23:40:30.814619 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 0 23:40:30.830751 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 799 23:40:30.830925 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 776 23:40:30.909501 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 0 23:40:30.909543 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 0 23:40:31.578588 IP 192.168.25.200.80 > 192.168.26.20.50810: tcp 0 23:40:31.578618 IP 192.168.25.200.80 > 192.168.26.20.50809: tcp 0 23:40:31.578639 IP 192.168.25.200.80 > 192.168.26.20.50808: tcp 0 23:40:35.266597 IP 192.168.25.200.80 > 192.168.26.20.50808: tcp 0 23:40:35.266619 IP 192.168.25.200.80 > 192.168.26.20.50809: tcp 0 23:40:35.516305 IP 192.168.25.200.80 > 192.168.26.20.50810: tcp 0 23:40:35.812030 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 733 23:40:35.812149 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 0 23:40:35.813357 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 733 23:40:35.813391 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 0 23:40:35.823793 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 794 23:40:35.824305 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 776 23:40:35.902929 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 0 23:40:35.902986 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 0 23:40:40.810130 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 733 23:40:40.810170 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 0 23:40:40.811211 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 733 23:40:40.811246 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 0 23:40:40.821519 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 800 23:40:40.823006 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 776 23:40:40.899932 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 0 23:40:40.900864 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 0 23:40:43.578720 IP 192.168.25.200.80 > 192.168.26.20.50810: tcp 0 23:40:43.578745 IP 192.168.25.200.80 > 192.168.26.20.50809: tcp 0 23:40:43.578757 IP 192.168.25.200.80 > 192.168.26.20.50808: tcp 0 23:40:45.820510 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 733 23:40:45.820563 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 0 23:40:45.821972 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 733 23:40:45.822014 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 0 23:40:45.833927 IP 192.168.25.76.80 > 192.168.26.20.50786: tcp 797 23:40:45.835247 IP 192.168.25.76.80 > 192.168.26.20.50787: tcp 776 23:40:45.923692 IP 192.168.26.20.50786 > 192.168.25.76.80: tcp 0 23:40:45.923742 IP 192.168.26.20.50787 > 192.168.25.76.80: tcp 0 -
I just updated my last answer cause the capture was wrong
-
@viragomann said in Cannot access webservers through vpn that are on a different gateway:
@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
if I masquerade the remote networks on the central mikrotik behind the lan interface, things works.
So the only two reasons for failing without that I can think off are
- the route doesn't work
- the destination server itself blocks the access
Blocking access from outside its own subnet is the default behavior of system firewalls, however, a webserver should be configured to accept access from anywhere. I assume, the server is accessible from the internet.
@silvered-dragon said in Cannot access webservers through vpn that are on a different gateway:
But honestly I'm not sure that masquerading the remote lan is a good practice.
The only one drawback is that you cannot identify the real source address on the destination device, as long as you do the masquerading only for the remote lan.
I'm 100% sure that there is no issue related on the servers side cause I created new vms with basic configuration, and I cannot access nothing in tcp even a simple debian+ssh
