Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
routing over VPN based on destination port
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Fri Mar 12, 2021 3:40 pm    Post subject: routing over VPN based on destination port Reply with quote

My company has a self host gitea system and the server is configured like this: Port 22 is open for everybody since you can only log in via SSH using keys only. Port 443 is accessible only from our company network.

Now that we've been working form home, we use VPN to connect to the company network and in order to reach port 443, I added this rule to my openvpn file

Code:

route GITEA_SERVER_IP 255.255.255.255 vpn_gateway


so dass openvpn adds the rule automatically. That works great, I can access the gitea frontend, however the whole traffic to the gitea server is now routed via the VPN which is very slow in comparison to my regular connection, so doing stuff like git clone is painfully slow. So ideally I'd like to route packages destined GITEA_SERVER:22 via my default geteway and the rest can stay as they are.

I've found this https://www.linuxquestions.org/questions/linux-networking-3/add-route-based-on-port-not-ip-486823/ which look simple enough, but it's not working for me and I don't know why and/or how to debug it.

So what I is (192.168.2.1 is the ip of my home router):

Code:

# make sure 3 is not used in /etc/iproute2/rt_tables
$ echo 3  GITEA >> /etc/iproute2/rt_tables
$ ip route add default via 192.168.2.1 dev eth0 table GITEA

$ ip route show table GITEA
default via 192.168.2.1 dev eth0

$ ip rule add from all fwmark 0x3 lookup GITEA

$ iptables -t mangle -I PREROUTING -p tcp --dport 22 --destination GITEA_SERVER_IP -j MARK --set-mark 3


But when I log in via SSH on the gitea server (I have user account on that server), and execute last, I can see my companie's IP and not my IP, meaning that it's still going via the VPN connection. The PREROUTING chain seems to be empty

Code:

$ iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

...


so I think that my iptables command did not work as intended. What am I doing wrong?
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
fedeliallalinea
Administrator
Administrator


Joined: 08 Mar 2003
Posts: 30842
Location: here

PostPosted: Fri Mar 12, 2021 4:04 pm    Post subject: Reply with quote

Moved from Portage & Programming to Networking & Security.
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Fri Mar 12, 2021 4:18 pm    Post subject: Re: routing over VPN based on destination port Reply with quote

Try it without --destination:
Code:
# iptables -t mangle -I PREROUTING -p tcp --dport 22 -j MARK --set-mark 3

If it doesnt work, we need the output from "ip route show all".
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21518

PostPosted: Fri Mar 12, 2021 4:53 pm    Post subject: Reply with quote

There are multiple PREROUTING chains, one in nat and one in mangle. You added to mangle, then viewed nat, so the absence is expected.
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Fri Mar 12, 2021 6:46 pm    Post subject: Re: routing over VPN based on destination port Reply with quote

pietinger wrote:
Try it without --destination:
Code:
# iptables -t mangle -I PREROUTING -p tcp --dport 22 -j MARK --set-mark 3

If it doesnt work, we need the output from "ip route show all".


I first tried without the --destination and it didn't work.

Code:

$ ip route show all
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.128 metric 2
10.8.0.0/24 via 10.8.0.9 dev tun0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
GITEA_SERVER_IP via 10.8.0.9 dev tun0
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.0.0/24 via 192.168.30.1 dev tun1
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.128 metric 2
192.168.15.0/24 dev in0 proto kernel scope link src 192.168.15.1
192.168.30.0/24 dev tun1 proto kernel scope link src 192.168.30.4
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1
192.168.188.0/24 via 10.8.0.9 dev tun0


Quick note about all my networks:


  • 192.168.2.0/24 is the network of my router, dhcp client runs on eth0
  • 192.168.15.0/25 is a network on a internal tuntap device that I use for testing my local dhcpd server and local bind rules inside my VirtualBox VMs
  • 192.168.100.0/24 is a network of a usb-eth device on my computer
  • tun0 is the vpn of my company (192.168.188.0/24 is the company network, 10.8.0.0 is the vpn network)
  • tun1 is another vpn of a sister company where I also work with, (192.168.0.0/24 is the sister company's network, 192.168.30.0 the vpn network)


Hu wrote:
There are multiple PREROUTING chains, one in nat and one in mangle. You added to mangle, then viewed nat, so the absence is expected.


I didn't realize that. That's the problem when you just copy&paste stuff without really understanding and hope that it works.

Code:

$ iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       tcp  --  0.0.0.0/0            88.99.182.189        tcp dpt:22 MARK set 0x3
MARK       tcp  --  0.0.0.0/0            88.99.182.189        tcp dpt:22 MARK set 0x3
MARK       tcp  --  0.0.0.0/0            88.99.182.189        tcp dpt:22 MARK set 0x3
MARK       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 MARK set 0x3
MARK       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 MARK set 0x3
MARK       tcp  --  0.0.0.0/0            88.99.182.189        tcp dpt:22 MARK set 0x3

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Fri Mar 12, 2021 8:28 pm    Post subject: Reply with quote

I am a little bit confused, so please correct me. As far as I understood you have a VPN to your main company (using tun0) and until now you did all of your 10.8.x.x - connections through this interface.

Now you want use this VPN only for https traffic to a special server. ssh traffic to this server shall now travel over eth0 connected to your private (dsl)-modem/router (having 192.168.2.1).

You said "[...] and execute last, I can see my companie's IP and not my IP [...]".

First question: Is this 10.8.0.10 (or 10.8.0.9) ?

Second: What is the configuration of your eth0 - is it 192.168.2.128 ?

Third: Do you do an ssh call to the external adress 88.99.182.189 or to the internal 10.8.x.x address ?

What is the output of "ip rule ls" and actually of "ip route show table GITEA" (and maybe "ip route show table all") ?
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Fri Mar 12, 2021 11:25 pm    Post subject: Reply with quote

Hi

Quote:

I am a little bit confused, so please correct me. As far as I understood you have a VPN to your main company (using tun0) and until now you did all of your 10.8.x.x - connections through this interface.


My eth0 gets 192.168.2.128 IP via DHCP. I then execute sudo openvpn mycompany.ovpn which is the one that generates the tun0 device and adds the routes. The network of my company is 192.168.188.0/24 and the VPN server (VPN from a Synology NAS) creates the 10.8.x.x network for the VPN, that's why my tun0's address is 10.8.0.10 and openvp adds the route 192.168.188.0/24 via 10.8.0.9 dev tun0 all by itself.

Quote:

Now you want use this VPN only for https traffic to a special server. ssh traffic to this server shall now travel over eth0 connected to your private (dsl)-modem/router (having 192.168.2.1).


yes, exactly. That gitea server port 443 can only be accessed from the company network, that's why I have this route GITEA_SERVER_IP via 10.8.0.9 dev tun0, but then all the traffic to that server goes through the VPN. And I would like that only 443 traffic to that server goes through the VPN and everything else through my default gw on eth0.

Quote:

First question: Is this 10.8.0.10 (or 10.8.0.9) ?


no, I see the pubic ip of my company. If I log in to the gitea server via vpn, then it goes to to 10.8.0.9 -> 192.168.188.1 -> company public ip -> gitea server


Quote:

Second: What is the configuration of your eth0 - is it 192.168.2.128 ?


yes, this is my configration:

Code:

$ cat /etc/conf.d/net
modules="dhcpcd"

config_eth0="dhcp"
dhcpcd_eth0="-t 40 -4" # Timeout after 10 seconds
dhcp_eth0="release nodns nontp nonis" # Only get an address

tuntap_in0="tap"
config_in0="192.168.15.1/24"


Quote:

Third: Do you do an ssh call to the external adress


to the external address, I never have to manually use the 10.x.x.x addresses.

Quote:

What is the output of "ip rule ls" and actually of "ip route show table GITEA" (and maybe "ip route show table all") ?


Code:

$ ip rule ls
0:   from all lookup local
32765:   from all fwmark 0x3 lookup GITEA
32766:   from all lookup main
32767:   from all lookup default

$ ip route show table GITEA
default via 192.168.2.1 dev eth0


thanks
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Sat Mar 13, 2021 2:55 am    Post subject: Reply with quote

As far as I see you did all correct (ok, you can drop some of your doubled (trippled) netfilter entries; but this doesnt harm). Ok, I dont know where all other routing-entries comes from, but I must not know it.

My last hope is:

You did all today ? (without rebooting) ... so maybe all old informations are still in the cache, so please try "ip route flush cache". (see more in chapter 4.0 and 4.1 of https://lartc.org/howto/index.html).
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Sun Mar 14, 2021 1:52 pm    Post subject: Reply with quote

pietinger wrote:
As far as I see you did all correct (ok, you can drop some of your doubled (trippled) netfilter entries; but this doesnt harm). Ok, I dont know where all other routing-entries comes from, but I must not know it.

My last hope is:

You did all today ? (without rebooting) ... so maybe all old informations are still in the cache, so please try "ip route flush cache". (see more in chapter 4.0 and 4.1 of https://lartc.org/howto/index.html).


So today I will only start my company vpn so that it generate less noise in the output of the routes.

So this is my routing table after I boot my system and no vpn is running:

Code:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    2      0        0 eth0
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
192.168.2.0     0.0.0.0         255.255.255.0   U     2      0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 in0

$ ip route show all
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.128 metric 2
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.128 metric 2
192.168.15.0/24 dev in0 proto kernel scope link src 192.168.15.1 linkdown


(I found that route -n is easier to read than if route show, that's why I'm including that as well).

After I connect to to my company VPN

Code:

# openvpn output
...
Sun Mar 14 14:40:47 2021 [synology.com] Peer Connection Initiated with [AF_INET]COMPANY_PUBLIC_IP:1194
Sun Mar 14 14:40:48 2021 TUN/TAP device tun0 opened
Sun Mar 14 14:40:48 2021 /bin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    2      0        0 eth0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
GITEA_SERVER    10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
192.168.2.0     0.0.0.0         255.255.255.0   U     2      0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 in0
192.168.188.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0

$ ip route show all
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.128 metric 2
10.8.0.0/24 via 10.8.0.5 dev tun0
10.8.0.1 via 10.8.0.5 dev tun0
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
GITEA_SERVER via 10.8.0.5 dev tun0
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.128 metric 2
192.168.15.0/24 dev in0 proto kernel scope link src 192.168.15.1 linkdown
192.168.188.0/24 via 10.8.0.5 dev tun0


Now I will execute the commands that I posted at my initial post

Code:

$ ip route add default via 192.168.2.1 dev eth0 table GITEA
$ ip route show table GITEA
default via 192.168.2.1 dev eth0
$ ip rule add from all fwmark 3 lookup GITEA
$ iptables -t mangle -I PREROUTING -p tcp --dport 22 -j MARK --set-mark 3

# I used --set-mark 3 instead of --set-mark 0x3 which doesn't seem to make any
# difference

iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 MARK set 0x3

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         


Is there a way to debug this and see if the ssh client packages get marked and with what they get marked? Could it be that I need to set 1 to some flags in /proc/net or something like that?
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Sun Mar 14, 2021 3:18 pm    Post subject: Reply with quote

So, the last command you did was
Code:
# ip route flush cache

? And it didnt helped ?

pablo_supertux wrote:
I used --set-mark 3 instead of --set-mark 0x3 which doesn't seem to make any difference

Yes. Three is always three - in decimal and in hexadecimal.

pablo_supertux wrote:
Is there a way to debug this and see if the ssh client packages get marked and with what they get marked? [...]

Yes. With tcpdump or something like "ethereal", now called "wireshark".

pablo_supertux wrote:
[...] Could it be that I need to set 1 to some flags in /proc/net or something like that?

I think it should be correct, because you are doing routing right now. Do you have this ?
Code:
# Disables packet forwarding
net.ipv4.ip_forward = 1
# Disables IP dynaddr
#net.ipv4.ip_dynaddr = 0
# Disable ECN
#net.ipv4.tcp_ecn = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Enable reverse path
net.ipv4.conf.all.rp_filter = 1

 [...]

# Disable source route
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv4.conf.default.accept_source_route = 0

Then you only need the correct kernel parameters and kernel modules (but I think you have them because you didnt get any error; in "Networking support ─> Networking options -> IP: advanced router" gives you: "IP: policy routing").
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Sun Mar 14, 2021 3:41 pm    Post subject: Reply with quote

pietinger wrote:
So, the last command you did was
Code:
# ip route flush cache

? And it didnt helped ?


No, I did not execute this command. Because I booted my system and I though I wouldn't need it. I just executed it right now and no, it didn't help. If I log in top the GITEA server, I still see my company's public IP.

Quote:

Yes. Three is always three - in decimal and in hexadecimal.


well I know that, but I didn't know whether it marks with an integer or a string in which case it might be different.

Quote:

Yes. With tcpdump or something like "ethereal", now called "wireshark".


I'll take a look at tcpdump. I started wireshark but the information overload is so great, I could not see anything at all.

Quote:

I think it should be correct, because you are doing routing right now. Do you have this ?


Code:

$ sysctl -a | grep "ip_forward\>\|ip_dynaddr\>\|tcp_ecn\>\|rp_filter\|accept_source_route"
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.accept_source_route = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.accept_source_route = 1
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.in0.accept_source_route = 1
net.ipv4.conf.in0.arp_filter = 0
net.ipv4.conf.in0.rp_filter = 0
net.ipv4.conf.lo.accept_source_route = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.tun0.accept_source_route = 1
net.ipv4.conf.tun0.arp_filter = 0
net.ipv4.conf.tun0.rp_filter = 0
net.ipv4.ip_dynaddr = 0
net.ipv4.ip_forward = 1
net.ipv4.tcp_ecn = 2
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.eth0.accept_source_route = 0
net.ipv6.conf.eth1.accept_source_route = 0
net.ipv6.conf.in0.accept_source_route = 0
net.ipv6.conf.lo.accept_source_route = 0
net.ipv6.conf.tun0.accept_source_route = 0


so tcp_ecn and rp_filter values are different to yours, could those be the problem?

Quote:

Then you only need the correct kernel parameters and kernel modules (but I think you have them because you didnt get any error; in "Networking support ─> Networking options -> IP: advanced router" gives you: "IP: policy routing").


yes, it's enabled

Code:

$ zcat /proc/config.gz  | grep CONFIG_IP_ADVANCED_ROUTER
CONFIG_IP_ADVANCED_ROUTER=y

_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Sun Mar 14, 2021 3:57 pm    Post subject: Reply with quote

pablo_supertux wrote:
so tcp_ecn and rp_filter values are different to yours, could those be the problem?

Maybe - I am unsure right now ... but ... just try it.

pablo_supertux wrote:
yes, it's enabled

This I didnt meant. Of course you must have it for routing. I meant the second one.

IP: advanced router -> CONFIG_IP_ADVANCED_ROUTER
IP: policy routing -> CONFIG_IP_MULTIPLE_TABLES

If you want to capture and analyze some packets with wireshark you almost have to look only into the very first packets ... so dont panic ;-)
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Sun Mar 14, 2021 4:07 pm    Post subject: Reply with quote

pietinger wrote:

This I didnt meant. Of course you must have it for routing. I meant the second one.

IP: advanced router -> CONFIG_IP_ADVANCED_ROUTER
IP: policy routing -> CONFIG_IP_MULTIPLE_TABLES


I have this set as well:

Code:

$ zcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES
CONFIG_IP_MULTIPLE_TABLES=y


I'll try it later, right now I have to do other stuff.
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Sun Mar 14, 2021 5:37 pm    Post subject: Reply with quote

pietinger wrote:
pablo_supertux wrote:
so tcp_ecn and rp_filter values are different to yours, could those be the problem?

Maybe - I am unsure right now ... but ... just try it.



well I tried setting those values to the same you wrote, that didn't help :(
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Sun Mar 14, 2021 5:58 pm    Post subject: Reply with quote

pablo_supertux wrote:
Is there a way to debug this and see if the ssh client packages get marked and with what they get marked?

I think you will not see it in a packet trace because these markings are handled internally in the kernel (a VLAN-Id you would see in a line trace).

At the moment I have no ideas ... maybe openvpn does weird things (for security reasons). Sorry. :-(
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4034
Location: Bavaria

PostPosted: Sun Mar 14, 2021 6:11 pm    Post subject: Reply with quote

If you have time you could do / test this:

You have some internal networks. Maybe you have a host with an sshd running there. You are able to connect via ssh to this host.

After a fresh reboot - WITHOUT starting openvpn - you can twist the port-22-route to this server to somewhere (like you did for your gitea server). If this works (then you should not be able to ssh-connect to this host anymore; with a wrong route to a wrong gateway it should timeout) you know it would work when it is not a vpn.

P.S. And dont forget to flush the cache.
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2929
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Sun Mar 14, 2021 7:17 pm    Post subject: Reply with quote

pietinger wrote:
If you have time you could do / test this:

You have some internal networks. Maybe you have a host with an sshd running there. You are able to connect via ssh to this host.

After a fresh reboot - WITHOUT starting openvpn - you can twist the port-22-route to this server to somewhere (like you did for your gitea server). If this works (then you should not be able to ssh-connect to this host anymore; with a wrong route to a wrong gateway it should timeout) you know it would work when it is not a vpn.

P.S. And dont forget to flush the cache.


good idea, i'll try that later. Thanks anyway
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum