Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internet not working with site-to-site ipsec #209

Open
mymyke opened this issue Mar 11, 2024 · 3 comments
Open

Internet not working with site-to-site ipsec #209

mymyke opened this issue Mar 11, 2024 · 3 comments

Comments

@mymyke
Copy link

mymyke commented Mar 11, 2024

I have a Site-to-site tunnel via ipsec wich is working fine.
There is a local range of 10.1.60.0/24 and the tunnel connects to a remote range 10.1.10.0/23.

IF i run updown.sh vti64 up everything that is sent over the tunnel still works. Everything else breaks.

If i run a ping from the local client 10.1.60.221 to the a remote host 10.1.10.17 (wich is inside the nw range configured in the gui) and watch it with tcpdump everything works fine:
"
switch0 P IP0 (invalid)
switch0.2 P IP 10.1.60.221 > 10.1.10.17: ICMP echo request, id 1, seq 848, length 40
br2 In IP 10.1.60.221 > 10.1.10.17: ICMP echo request, id 1, seq 848, length 40
vti64 Out IP 10.1.60.221 > 10.1.10.17: ICMP echo request, id 1, seq 848, length 40
vti64 In IP 10.1.10.17 > 10.1.60.221: ICMP echo reply, id 1, seq 848, length 40
br2 Out IP 10.1.10.17 > 10.1.60.221: ICMP echo reply, id 1, seq 848, length 40
"

But if i ping something else like 9.9.9.9 suddenly the paket stops at "vti64 IN" but never shows up in the br2 interface.
"
switch0 P IP0 (invalid)
switch0.2 P IP 10.1.60.221 > 9.9.9.9: ICMP echo request, id 1, seq 851, length 40
br2 In IP 10.1.60.221 > 9.9.9.9: ICMP echo request, id 1, seq 851, length 40
vti64 Out IP 10.1.60.221 > 9.9.9.9: ICMP echo request, id 1, seq 851, length 40
vti64 In IP 9.9.9.9 > 10.1.60.221: ICMP echo reply, id 1, seq 851, length 40
"

For testing i added FW Rules to allow everthing.

the config file uses FORCED_SOURCE_INTERFACE= br2, BYPASS_MASQUERADE_IPV4="ALL" VPN_PROVIDER="nexthop", MSS_CLAMPING_IPV4="1382", DEV=vti64, VPN_ENDPOINT_IPV4="10.1.10.254". Everything else is like the default values.

Ip rule output looks like:
0: from all lookup local
99: from all fwmark 0x169 lookup 101
220: from all lookup 220
32000: from all lookup main
32500: from to lookup 201.eth8
32501: from all fwmark 0x1a0000/0x7e0000 lookup 201.eth8
32503: from lookup 201.eth8
32765: from all fwmark 0x10000/0x10000 lookup 251.blackhole
32766: from all lookup 201.eth8
32767: from all lookup default

The important stuff from IP r list tables all:
0.0.0.0/1 via 10.1.10.254 dev vti64 table 101
blackhole default table 101
128.0.0.0/1 via 10.1.10.254 dev vti64 table 101
default via dev eth8 table 201.eth8 proto dhcp
blackhole default table 251.blackhole proto PBR
10.1.10.0/23 dev vti64 proto static scope link metric 30
10.1.60.0/24 dev br2 proto kernel scope link src 10.1.60.254
dev eth8 proto kernel scope link src

I can't figure out, why packages that come in from the tunnel wont show up in br2.
Can someone help me find the bug?

@mymyke
Copy link
Author

mymyke commented Mar 18, 2024

I figured out, that the Problem was with Reverse Path filtering (https://sysctl-explorer.net/net/ipv4/rp_filter/)
I currently solved it by setting rp_filter for the interfaces "/all/" and "/vti64/" to "0".

Is this the desired behavior or is there a better solution to keep Reverse Path filtering active?

@hfagelnour
Copy link

I figured out, that the Problem was with Reverse Path filtering (https://sysctl-explorer.net/net/ipv4/rp_filter/) I currently solved it by setting rp_filter for the interfaces "/all/" and "/vti64/" to "0".

Is this the desired behavior or is there a better solution to keep Reverse Path filtering active?

May I ask how to do this please? and would it work on OpenVPN Site2Site

@Haxim
Copy link

Haxim commented Sep 19, 2024

I figured out, that the Problem was with Reverse Path filtering (https://sysctl-explorer.net/net/ipv4/rp_filter/) I currently solved it by setting rp_filter for the interfaces "/all/" and "/vti64/" to "0".

Is this the desired behavior or is there a better solution to keep Reverse Path filtering active?

Thanks so much for this! Was tearing my hair out for a bit trying to figure it out.
I'll probably try using the post-up hook to set rp_filter using sysctl in the vpn.conf file like so (not sure if there's a better way):

hooks_up() {
    /sbin/sysctl -w net.ipv4.conf.vti64.rp_filter=0
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants