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

Unable to connect to the server instance (OpenWrt) #523

Open
o-alquimista opened this issue Apr 28, 2024 · 5 comments
Open

Unable to connect to the server instance (OpenWrt) #523

o-alquimista opened this issue Apr 28, 2024 · 5 comments

Comments

@o-alquimista
Copy link

o-alquimista commented Apr 28, 2024

Client

System info:

  • Fedora 40 x86_64 laptop
  • firewalld active, default config
  • SELinux enforcing
  • udp2raw binary: udp2raw_amd64
$ sudo udp2raw_amd64 -c -l 0.0.0.0:55820 -r 203.0.113.100:4096 -k "password_removed" --raw-mode faketcp -a
[2024-04-28 16:49:08][INFO]argc=11 udp2raw_amd64 -c -l 0.0.0.0:55820 -r 203.0.113.100:4096 -k password_removed --raw-mode faketcp -a 
[2024-04-28 16:49:08][INFO]parsing address: 0.0.0.0:55820
[2024-04-28 16:49:08][INFO]its an ipv4 adress
[2024-04-28 16:49:08][INFO]ip_address is {0.0.0.0}, port is {55820}
[2024-04-28 16:49:08][INFO]parsing address: 203.0.113.100:4096
[2024-04-28 16:49:08][INFO]its an ipv4 adress
[2024-04-28 16:49:08][INFO]ip_address is {203.0.113.100}, port is {4096}
[2024-04-28 16:49:08][INFO]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=password_removed local_addr=0.0.0.0:55820 remote_addr=203.0.113.100:4096 socket_buf_size=1048576 
[2024-04-28 16:49:08][WARN]you can run udp2raw with non-root account for better security. check README.md in repo for more info.
[2024-04-28 16:49:08][INFO]remote_ip=[203.0.113.100], make sure this is a vaild IP address
[2024-04-28 16:49:08][INFO]const_id:9bbac27b
[2024-04-28 16:49:08][INFO]run_command iptables -N udp2rawDwrW_9bbac27b_C0
[2024-04-28 16:49:08][INFO]run_command iptables -F udp2rawDwrW_9bbac27b_C0
[2024-04-28 16:49:08][INFO]run_command iptables -I udp2rawDwrW_9bbac27b_C0 -j DROP
[2024-04-28 16:49:08][INFO]run_command iptables -I INPUT -s 203.0.113.100 -p tcp -m tcp --sport 4096 -j udp2rawDwrW_9bbac27b_C0
[2024-04-28 16:49:08][WARN]auto added iptables rules
[2024-04-28 16:49:08][INFO]source_addr is now 192.168.0.110
[2024-04-28 16:49:08][INFO]using port 47991
[2024-04-28 16:49:08][INFO]state changed from client_idle to client_tcp_handshake
[2024-04-28 16:49:08][INFO](re)sent tcp syn
[2024-04-28 16:49:09][INFO](re)sent tcp syn
[2024-04-28 16:49:10][INFO](re)sent tcp syn
[2024-04-28 16:49:12][INFO](re)sent tcp syn
[2024-04-28 16:49:13][INFO](re)sent tcp syn

Replaced actual public address with 203.0.113.100

Server

System info:

/etc/config/firewall

(...)
config include 'Include_Udp2raw'          
        option type 'nftables'        
        option path '/etc/udp2raw.nft'
        option position 'chain-pre'               
        option chain 'input'

/etc/udp2raw.nft

tcp dport 4096 counter drop

/etc/init.d/udp2raw

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=95
STOP=01

start_service() {
	procd_open_instance
	procd_set_param command udp2raw -s -l 0.0.0.0:4096 -r 127.0.0.1:55820 -k "password_removed" --raw-mode faketcp
	procd_set_param stdout 1
	procd_set_param stderr 1
	procd_close_instance
}
  • If I add an ACCEPT rule for port 4096 - instead of DROP, the client reaches the client_ready state - the connection appears to be successful. But then I cannot start Wireguard on the client because the port is already being used (by udp2raw).
  • If I don't add any rule for udp2raw, I get the same output I pasted in the client section above ([INFO](re)sent tcp syn echoing forever). It seems the DROP rules are not working as expected.
@wangyu-
Copy link
Owner

wangyu- commented Apr 29, 2024

If I add an ACCEPT rule for port 4096 - instead of DROP, the client reaches the client_ready state - the connection appears to be successful. But then I cannot start Wireguard on the client because the port is already being used (by udp2raw).

"Wireguard port being used" is not relevant to iptables or nftables rules or udp2raw can connect or not.

If it says port occupied there must be some problem in otherwhere.

Check your settings of wireguard, and see if you specific some source port to use. Remove the source port or change to another source port.

On the client side it's typically not necessary to specify a source port.

@o-alquimista
Copy link
Author

o-alquimista commented May 6, 2024

I commented out the ListenPort in the wireguard client config, so it picks a random port on startup. After bringing wireguard up, I take note of the port number and pass it to the udp2raw client command: -l0.0.0.0:<random_port>. But sadly it's still not working.
It's not completing the handshake. It's like client and server are not agreeing on something. I even see "new packet from 127.0.0.1:55820".

I'm about to give up trying to run udp2raw on OpenWrt. I've used it successfully before on a Raspberry Pi. I just wonder if it's possible to keep wireguard on the router, and run udp2raw somewhere else in the LAN.


EDIT: I realized I should not use the ListenPort (random) in the udp2raw -l 0.0.0.0:<port> argument, but instead use the Endpoint (55820) port.

@o-alquimista
Copy link
Author

o-alquimista commented Jun 10, 2024

I moved the udp2raw server to a system running Alpine Linux, and the problem persists.

[2024-06-10 13:27:04][INFO]argc=10 udp2raw -c -l 0.0.0.0:51820 -r PUBLIC_IPV4:4096 -k PASSWORD --raw-mode faketcp 
[2024-06-10 13:27:04][INFO]parsing address: 0.0.0.0:51820
[2024-06-10 13:27:04][INFO]its an ipv4 adress
[2024-06-10 13:27:04][INFO]ip_address is {0.0.0.0}, port is {51820}
[2024-06-10 13:27:04][INFO]parsing address: PUBLIC_IPV4:4096
[2024-06-10 13:27:04][INFO]its an ipv4 adress
[2024-06-10 13:27:04][INFO]ip_address is {PUBLIC_IPV4}, port is {4096}
[2024-06-10 13:27:04][INFO]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=PASSWORD local_addr=0.0.0.0:51820 remote_addr=PUBLIC_IPV4:4096 socket_buf_size=1048576 
[2024-06-10 13:27:04][WARN]you can run udp2raw with non-root account for better security. check README.md in repo for more info.
[2024-06-10 13:27:04][INFO]remote_ip=[PUBLIC_IPV4], make sure this is a vaild IP address
[2024-06-10 13:27:04][INFO]const_id:7f9d8b1e
[2024-06-10 13:27:04][WARN] -a has not been set, make sure you have added the needed iptables rules manually
[2024-06-10 13:27:04][INFO]source_addr is now 192.168.1.108
[2024-06-10 13:27:04][INFO]using port 62321
[2024-06-10 13:27:04][INFO]state changed from client_idle to client_tcp_handshake
[2024-06-10 13:27:04][INFO](re)sent tcp syn
[2024-06-10 13:27:04][INFO]state changed from client_tcp_handshake to client_handshake1
[2024-06-10 13:27:04][INFO](re)sent handshake1
[2024-06-10 13:27:04][INFO]changed state from to client_handshake1 to client_handshake2,my_id is 364ef6d,oppsite id is 11b62c6
[2024-06-10 13:27:04][INFO](re)sent handshake2
[2024-06-10 13:27:04][INFO]changed state from to client_handshake2 to client_ready

At this point I turn on Wireguard...

[2024-06-10 13:27:12][INFO]new packet from 127.0.0.1:37727,conv_id=40053fc7
[2024-06-10 13:27:22][INFO]state back to client_idle from  client_ready bc of server-->client direction timeout
[2024-06-10 13:27:23][INFO]source_addr is now 192.168.2.4
[2024-06-10 13:27:23][INFO]using port 33196
[2024-06-10 13:27:23][INFO]state changed from client_idle to client_tcp_handshake
[2024-06-10 13:27:23][INFO](re)sent tcp syn
[2024-06-10 13:27:24][INFO](re)sent tcp syn
[2024-06-10 13:27:25][INFO](re)sent tcp syn
[2024-06-10 13:27:26][INFO](re)sent tcp syn

My steps:

  • Start udp2raw (it will reach client_ready)
  • Start wireguard (udp2raw will be back to client_idle)

Relevant log line:

[INFO]state back to client_idle from  client_ready bc of server-->client direction timeout

@wangyu- What does this mean?

Server info:

  • Alpine Linux (arm64) on Raspberry Pi 4B
  • nftables

@wangyu-
Copy link
Owner

wangyu- commented Jun 10, 2024

It simply means the connection is broken.

Have you added the route exception for udp2raw?

https://github.com/wangyu-/udp2raw/wiki/udp2raw-openvpn-config-guide

If you want to transparently redirect traffic by VPN, it's very important to add a route exception (on client side) so that the VPN won't hijack udp2raw's traffic. Since your VPN traffic goes throught udp2raw, if your VPN hijacks udp2raw's traffic then there will be a traffic loop and your udp2raw will lost connection

@wangyu-
Copy link
Owner

wangyu- commented Jun 10, 2024

try on client side:

ip route add YOUR_SERVER_IP via  YOUR_GATEWAY

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

2 participants