V2raya tun0 LAN no ping

Installing and Using OpenWrt
1

Hello there!
I have a problem with using tunnel stolen from sing-box config, which seems to work with v2rayA: when state is ready -- traffic goes in, when its stopped -- no traffic goes in. I assume that v2rayA hooks tun0 interface.
Here's the deal: there is no ping from LAN to internet. At all.
Please help!
Thx in advance

here's my network config

config interface 'tun0'
  option device 'tun0'
  option proto 'static'
  option ipaddr '172.16.250.1'
  option netmask '255.255.255.0'
  list dns '1.1.1.1'
  option gateway '192.168.1.1'

firewall config:

config zone
  option name 'tun'
  option forward 'ACCEPT'
  option output 'ACCEPT'
  option input 'ACCEPT'
  option masq '1'
  option mtu_fix '1'
  option device 'tun0'
  option family 'ipv4'
config forwarding
  option name 'lan-tun'
  option dest 'tun'
  option src 'lan'
  option family 'ipv4'

pinging from local pc with firewall enabled:

~ % ping google.com
PING google.com (173.194.221.102): 56 data bytes
92 bytes from openwrt.lan (192.168.2.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 d393   0 0000  3f  01 5967 192.168.2.221  173.194.221.102

pinging without firewall (disabled):

~ % ping google.com
PING google.com (142.251.1.138): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- google.com ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Π‘Π½ΠΈΠΌΠΎΠΊ экрана 2024-11-28 Π² 18.59.37
Π‘Π½ΠΈΠΌΠΎΠΊ экрана 2024-11-28 Π² 18.59.371950Γ—698 55.4 KB

2

Looks like your DNS is working fine at least.

Run this:

root@OpenWrt:~# opkg install tcpdump
root@OpenWrt:~# tcpdump -nni any 'host 1.1.1.1'

Then run ping 1.1.1.1 (from same machine you just tried to ping from).

Then post results.

2 Likes
3

This is definitely wrong. The gateway needs to be an external device (not one of your own IPs) that is directly reachable on the interface, In other words it is the next router in line to the Internet. On a point to point tunnel it isn't necessary to specify a gateway, only that the default route is via that tunnel,

So check your routing table (ip -4 route show or the legacy command route). I don't know v2ray in particular, but two things have to be in the kernel routing for a "whole house" VPN client to work. The default route is via the tunnel, and there is an exception host route (/32) for the encrypted packets to go to the VPN server via the regular wan.

Remember that the firewall rules only say what is allowed to happen. Setting an allow forward from lan to vpn does not tell the kernel to actually route traffic that way, That is in the routing table.

2 Likes
4

Thx for the reply!
Here it is:

5

The next gateway 192.168.1.1 is an endpoint home router which is linked to the ISP


root@OpenWrt:~# ip -4 route show
default via 192.168.1.1 dev eth1 proto static src 192.168.1.232
default via 192.168.1.1 dev phy0-sta0 proto static src 192.168.1.229 metric 100
172.16.250.0/30 dev tun0 proto kernel scope link src 172.16.250.1
172.16.250.0/24 dev tun0 proto kernel scope link src 172.16.250.1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.232
192.168.1.0/24 dev phy0-sta0 proto static scope link metric 100
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1
6

Looks like the ping gets to OpenWrt "br-lan" interface at least !

Bottom one has metric 100, so it will choose the top one and forward out of eth1 - but only after packet passes NAT and firewall.

Probably there are no NAT rules to rewrite the destination IP. Perhaps the source IP gets rewritten by a masquerade flag.

Could be blocked in firewall. Which zone contains "br-lan" and which zone contains "eth1", and do you have a zone rule:

br-lan-zone --> eth1-zone FORWARD ACCEPT

?

1 Like
7

That is true

Tried pinging with and without masq flag -- same siht

No, as i mentioned in first post pinging without firewall (service firewall stop) gives

Request timeout for icmp_seq 0

No, shouid I?
All zones are mentioned in first post

8

If you want the ping to go out that interface, then yes.

If you expect the ping to go via the tunnel, then you just need an OUTPUT ACCEPT rule on eth1 to allow traffic from OpenWrt itself (vpn software) to the VPN gateway.

In the latter case, still necessary with a FORWARD ACCEPT rule, but the direction would be from the br-lan zone to the tun0 zone instead.

Is the openwrt box connected to the network where the upstream router sits two times, or what is going on here?

Both via eth1 (wired) and via wifi (in client mode)?

Otherwise, I'm not sure where that last entry, the one that points to dev phy-sta0 is coming from.

Can you post the entire /etc/config/network so we can try and figure that out?

Normally, the upstream router / gateway needs to be what is called "directly reachable" by the box you are looking at.

Here, for example, OpenWrt participates in the network 172.16.250.x ("x" because netmask is 255.255.255.0).

"Directly reachable" means that the upstream router's IP (ie. the "gateway" line above) should fall somewhere in the range 172.16.250.1 and 172.16.250.254.

Technically this is only a hard rule for interface types that rely on protocols like ARP to resolve IP addresses to MAC addresses...

(VPN interfaces for example can function entirely without any gateway IP address, and instead the gateway can simply be a pointer to the virtual network device.)

Still though, the above gateway definition on tun0 is probably wrong?

1 Like
9

There still isn't a route to 0.0.0.0 via VP tunnel. This must be in place before the firewall will have any effect. Most VPN software such as OpenVPN and WireGuard installs its routes within the program after the tunnel is connected. I don't know if v2raya is supposed to work that way or it needs the routes to be directly configured.

Also when the 0.0.0.0 route is via a VPN tunnel, it will prevent encrypted packets from leaving the router properly unless there is another route for them to the single IP of the VPN server via regular WAN. VPN software again usually installs this.

2 Likes
10

its already is. Check first post for sceenshot

dev phy-sta0 is a wifi client

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc3:6c9f:a14f::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'
	list ports 'eth0'
	list ports 'eth0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '192.168.1.1'
	option dns '192.168.1.1'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
	option force_link '1'
	option broadcast '1'
	option peerdns '0'
	list dns '1.1.1.1'

config interface 'wan6'
	option device 'eth1'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'

config interface 'tun0'
	option device 'tun0'
	option proto 'static'
	option ipaddr '172.16.250.1'
	option netmask '255.255.255.0'
	list dns '1.1.1.1'
	option gateway '192.168.1.1'

config interface 'trm_wwan'
	option proto 'dhcp'
	option metric '100'

config interface 'trm_wwan6'
	option device '@trm_wwan'
	option proto 'dhcpv6'

config interface 'LTE'
	option proto 'dhcp'
	option device 'eth2'
	option auto '0'

oot@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config forwarding
	option name 'lan-tun'
	option dest 'tun'
	option src 'lan'
	option family 'ipv4'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'tun'
	option forward 'ACCEPT'
	option output 'ACCEPT'
	option input 'ACCEPT'
	option mtu_fix '1'
	option device 'tun0'
	option family 'ipv4'
	option masq '1'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'
	list network 'trm_wwan'
	list network 'trm_wwan6'
	list network 'tun0'
	list network 'LTE'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option family 'ipv4'
	option target 'ACCEPT'
	list icmp_type 'echo-request'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include 'pbr'
	option fw4_compatible '1'
	option type 'script'
	option path '/usr/share/pbr/firewall.include'

config rule
	option name 'Allow-ZTE'
	option src 'lan'
	option proto 'tcp'
	option target 'ACCEPT'
	option family 'ipv4'
	option dest 'wan'
	list dest_ip '192.168.0.1'
	list dest_ip '192.168.1.4'

config forwarding
	option src 'lan'
	option dest 'wan'
11

There is quite a bit wrong here. So much that I'd suggest resetting the config to defaults and starting over. First get ordinary lan->wan routing working. All the instructions for setting up a VPN are based on the router being functional as lan->wan first. Choose whether to use LTE, WiFi or Ethernet for your wan and disable the others.

For redirecting the whole network's Internet usage into a VPN which terminates at the OpenWrt main router, placing the VPN interface in the existing wan zone is appropriate. You have tun0 in two zones which cannot work. A device or network must be in exactly one zone.

2 Likes
12

its working just fine. The problem is tunnel interface only

fixed

13

It doesn't work that way. I checked
LAN must be strictly directed to tun0 or v2rayA stops working properly

1 Like
14

Guys, I think I've found a viable solution. Here's a snippet

echo "200 tun0_table" >> /etc/iproute2/rt_tables

# Add a rule to use the new routing table for ICMP packets
ip rule add proto icmp table tun0_table

# Add a default route in the new table to use tun0
ip route add default dev tun0 table tun0_table

# Add iptables rules to mark ICMP packets
iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p icmp -j MARK --set-mark 1

# Add a rule to use the new routing table for marked packets
ip rule add fwmark 1 table tun0_table

However, It returns an error when I type first line

ip rule add proto icmp table tun0_table

Error: argument "table" is wrong: "protocol" value is invalid
15

ipproto icmp ?

1 Like
16

If you want to use Policy Based Routing this way you should look into using netifd: https://openwrt.org/docs/guide-user/network/routing/pbr_netifd
ipproto was recently added so only available on the newest snapshots

If you want to do it manually it is ipproto and not proto

1 Like
17

As I said before, usually VPN software has a provision for it to install the necessary routes automatically. However I don't know if v2ray includes this.

Routes can also be declared within /etc/config/network or using a helper package (typically pbr) is a better way than scripting calls to ip etc. In /etc/config/network I think the syntax for setting up a second routing table is:

config rule
   option source 'lan'
   option table 200

config route
   option table 200
   option interface 'tun0'
   option target '0.0.0.0/0'
2 Likes
18

and for ipproto (but only on recent snapshots):

config rule
    option ipproto '1'   #for ICMP see https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
    option table 200
1 Like
19

That snippet from my prev. post (or your config) made traffic to drop in WAN. Shti...
I've reverted backup config.

20

Yes that is intended. You want everything from lan to forward to the Internet via VPN instead. If the VPN is not working for some other reason, lan machines will have no Internet access.

Internet use which originates from inside the router (such as the encrypted packets from the v2raya client process) would still go out on the wan directly.

2 Likes