WireGuard or OpenVPN

alexp1984 · Thu Aug 15, 2024 4:07 pm

Hi I have been reading about setting up VPN access to my homenetwork (I will setup specific VLANs for specific IPs to have access) and can't workout what the difference is or how to do it. Assuming I name the main VLAN10 (192.168.88.0/24) and the publicly accessible one VLAN20 (192.168.89.0/24), which is better and how would I set this up? The devices on VLAN10 will need access to some IPs on VLAN20.

Thanks!

JohnTRIVOLTA · Thu Aug 15, 2024 4:13 pm

All networks in the router are routed by default, either VLANs, VPNs, etc. Everything else, as restrictions, is done in the firewall!

anav · Thu Aug 15, 2024 4:28 pm

wIreguard

alexp1984 · Thu Aug 15, 2024 6:06 pm

wIreguard

hey thanks, so how do i set this up so resources can be accessed from an Android phone or Windows? If I understand it, I need a config file (public & private keys?) from the clients that I upload and that's it? Then I just hit connect on the client? Can I set up access from specific MAC addresses or would it have to be by IP?

anav · Thu Aug 15, 2024 6:22 pm

need a wireguard capable device as server for handshake.
do you have a MT router or device?
Do you have a public IP or can you forward ports from an upstream ISP router device?

alexp1984 · Thu Aug 15, 2024 9:12 pm

i have a hex s
i can get a static IP from my ISP ir use a DDNS such as noip

anav · Thu Aug 15, 2024 9:15 pm

Setting up vlans --> viewtopic.php?t=143620

nichky · Fri Aug 16, 2024 6:06 am

wIreguard

depend of the situation.
Regarding the performance - I will alway go with WG, however if the IPS is blocking the ports, then OVPN is better solution, as no one is blocking 443.
One more note, OVPN interface is exactly the same as physical interface (mac-address), capable for vlans.

anav · Fri Aug 16, 2024 2:13 pm

wIreguard
depend of the situation.
Regarding the performance - I will alway go with WG, however if the IPS is blocking the ports, then OVPN is better solution, as no one is blocking 443.
One more note, OVPN interface is exactly the same as physical interface (mac-address), capable for vlans.

....

nichy-special.jpg

nichky · Fri Aug 16, 2024 3:26 pm

@anav

i was waiting you there.

For some reason that will not work.

I've tested today, OVPN does.

i'm connected to public internet(hotspot), where all the ports have been disabled except 443

optio · Fri Aug 16, 2024 5:17 pm

One more note, OVPN interface is exactly the same as physical interface (mac-address), capable for vlans.

It depens on OVPN server mode, ethernet is L2 and ip is L3. It is not clear by OP is this is for site-to-site connection or for connection directly from remote non router clients (aka BTH), in such case ip mode needs to be used if mobile clients needs to be connected because OVPN cliient for moble devices doesn't support ethernet mode.
If VLANS connections are managed by router, firewall rules can be used for managing connections between them and OVPN, Wireguard or any VPN on L3.

optio · Fri Aug 16, 2024 5:31 pm

For some reason that will not work.

I've tested today, OVPN does.

i'm connected to public internet(hotspot), where all the ports have been disabled except 443

Is your OVPN server running on TCP? Wireguard works only on UDP. If such is the case, hotspot is probably allowing only TCP 443 connections.

anav · Fri Aug 16, 2024 6:44 pm

@anav

i was waiting you there.

For some reason that will not work.

I've tested today, OVPN does.

i'm connected to public internet(hotspot), where all the ports have been disabled except 443

Sounds like a personal problem, no reason why 443 UDP should not work, unless its a company that restricts ports.......

optio · Fri Aug 16, 2024 6:59 pm

It seems it is browse-web-only public hotspot on which even QUIC is not supported

Btw, it is possible to tunnel WG over TCP, but requires tunneling tool in container and client side...

anav · Fri Aug 16, 2024 9:54 pm

Where did the OP say anything about hotspot?? I must be blind.

optio · Fri Aug 16, 2024 10:19 pm

@nichky did, I was replying for his case

anav · Fri Aug 16, 2024 10:54 pm

Ahh okay, didnt realize nichky was asking for help!

optio · Fri Aug 16, 2024 11:04 pm

Not sure if he was asking for help, just to find a reason for:

For some reason that will not work.

nichky · Sat Aug 17, 2024 4:31 am

im not asking for a help , all i'm saying is that you can't use WG in any situation.

If the IPS is blocking the ports , and even if you play with 433 that will not help to establish connections. Not sure why is that,

So in this case you have to use OVPN

erlinden · Sat Aug 17, 2024 9:14 am

If the IPS is blocking the ports , and even if you play with 443 that will not help to establish connections. Not sure why is that,

Are you stating that on the same port and with same protocol OpenVPN will work while Wireguard does (sometimes) not?

nichky · Sat Aug 17, 2024 11:37 am

nichky · Sat Aug 17, 2024 11:39 am

i'll be visiting the site next week, and i'll get some pictures and add here

optio · Sat Aug 17, 2024 11:50 am

Doesn't make sense unless OVPN is running on TCP or there is WG protocol blocking on DPI level on that site which is very unlikely for public hostspot.

nichky · Sat Aug 17, 2024 12:16 pm

any volotier that want to join ?

optio · Sat Aug 17, 2024 12:26 pm

Paste output from

/interface/ovpn-server/server export

just to be sure

nichky · Sat Aug 17, 2024 2:14 pm

/interface ovpn-server server
set auth=sha1,sha256 certificate=Server cipher=aes128-cbc default-profile=ovpn enabled=\
    yes netmask=22 port=443

optio · Sat Aug 17, 2024 2:29 pm

No protocol defined in config, default is TCP...
From https://help.mikrotik.com/docs/display/ROS/OpenVPN:

protocol (tcp | udp; Default: tcp) Indicates the protocol to use when connecting with the remote endpoint.

So above assumptions regarding different protocols are in use (TCP vs UDP) where correct.

Set protocol to UDP in server and client config and see how it will not connect on mentioned hotspot...

nichky · Sat Aug 17, 2024 2:35 pm

the protocol for OVPN is TCP, i'll try with UDP.

What you are saying make sense

optio · Sat Aug 17, 2024 2:49 pm

For such cases I have failovers, Wireguard as primary VPN on UDP, OVPN on TCP 443 as 1st failover if UDP is filtered and Wireguard over obfuscated TLS tunnel on TCP 443 as 2nd failover if DPI firewall blocks VPN access. Starting them on demand with SMS commands.

anav · Sat Aug 17, 2024 8:35 pm

Hey have you got a config for wireguard over TLS, that sounds MF. sexy.

optio · Sat Aug 17, 2024 11:40 pm

I'm tunneling WG with Xray running in container with this image without modifications. Tunneling is performed over Xray XTLS protocol, a custom TLS (REALITY) with SNI spoofing (from www.microsoft.com in my case). Xray config mostly is taken from here, on this page are more details about how it works and limitations regarding mobile devices for direct connection - in such case RoadWarrior router can be configured for tunneling ROS-to-ROS.

For configs .txt extension is added for .json files to be able to attach.

Server side config - ROS
Xray (in container):

xray_config_server.json.txt

File is actually placed in container on path /etc/xray/config.json, and /etc/xray dir. is mounted for presistance.

Nat rule for Xray port forward:

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=443 in-interface-list=WAN protocol=tcp to-addresses=192.168.200.6

Wireguard:

/interface wireguard
add listen-port=12884 mtu=1300 name=wireguard2 private-key="<wg_priv_key>"
/interface wireguard peers
add allowed-address=192.168.203.2/32 interface=wireguard2 name=peerX public-key="<wg_pub_key>"

ROS firewall, routing and other rules for WG depends on use case, in my case there are no special rules just because of Xray tunnel except that Xray container has access on input chain for UDP 12884 (WG port) for establishing connection to ROS WG, also WG port in such case doesn't need to be open for public access if only over tunnel will be used.

Client side config - MacOS
Xray (cli tool from MacPorts):

xray_config_client.json.txt

Wireguard (App Store app):

[Interface]
PrivateKey = <wg_peer_priv_key>
Address = 192.168.203.2/32
DNS = <my_dns_in_container_or_any...>
MTU = 1300

[Peer]
PublicKey = <wg_peer_pub_key>
AllowedIPs = <ip_range_excluding_server_side_ip>
Endpoint = 127.0.0.1:12884
PersistentKeepalive = 25

When all is configured, first Xray connection needs to be established and tunnel port on localhost (127.0.0.1:12884) on client side will be open, then it is possible to connect WG over it.

If you want connection as regular TLS with own cert/key (no SNI spoof) I can write Xray configs for that...

nichky · Thu Aug 22, 2024 4:58 am

@optio

just ive tested.

The hotspot (public internet library) is only allowing TCP 443, that why WG is not going to work, as this allowing only UDP.

You was right

stmx38 · Thu Aug 22, 2024 7:26 am

Had similar situation, in Airport via public Wi-Fi - Wireguard doesn't work.

The solution can be, to use WG/UDP and OVPN/TCP and both on 443 port.

dcavni · Fri Nov 01, 2024 4:09 pm

I'm tunneling WG with Xray running in container with this image without modifications. Tunneling is performed over Xray XTLS protocol, a custom TLS (REALITY) with SNI spoofing (from www.microsoft.com in my case). Xray config mostly is taken from here, on this page are more details about how it works and limitations regarding mobile devices for direct connection - in such case RoadWarrior router can be configured for tunneling ROS-to-ROS.

For configs .txt extension is added for .json files to be able to attach.

Server side config - ROS
Xray (in container): xray_config_server.json.txt
File is actually placed in container on path /etc/xray/config.json, and /etc/xray dir. is mounted for presistance.

Nat rule for Xray port forward:
Code: Select all
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=443 in-interface-list=WAN protocol=tcp to-addresses=192.168.200.6
Wireguard:
Code: Select all
/interface wireguard
add listen-port=12884 mtu=1300 name=wireguard2 private-key="<wg_priv_key>"
/interface wireguard peers
add allowed-address=192.168.203.2/32 interface=wireguard2 name=peerX public-key="<wg_pub_key>"
ROS firewall, routing and other rules for WG depends on use case, in my case there are no special rules just because of Xray tunnel except that Xray container has access on input chain for UDP 12884 (WG port) for establishing connection to ROS WG, also WG port in such case doesn't need to be open for public access if only over tunnel will be used.

Client side config - MacOS
Xray (cli tool from MacPorts):
xray_config_client.json.txt
Wireguard (App Store app):
Code: Select all
[Interface]
PrivateKey = <wg_peer_priv_key>
Address = 192.168.203.2/32
DNS = <my_dns_in_container_or_any...>
MTU = 1300

[Peer]
PublicKey = <wg_peer_pub_key>
AllowedIPs = <ip_range_excluding_server_side_ip>
Endpoint = 127.0.0.1:12884
PersistentKeepalive = 25
When all is configured, first Xray connection needs to be established and tunnel port on localhost (127.0.0.1:12884) on client side will be open, then it is possible to connect WG over it.

If you want connection as regular TLS with own cert/key (no SNI spoof) I can write Xray configs for that...

Can you add configuration for client side if client is another Mikrotik device?

optio · Sat Nov 02, 2024 6:17 pm

Unfortunately I don't have ROS device or CHR running on remote site, to do it in local CHR is a bit complicated because I need to create some routing rules on host computer to test routing over CHR running locally, don't have time to play with now...
I can give some tips related to site-to-site client side configuration:

add Xray container and put client config json at same name and path mentioned as for server setup

create ROS wireguard client peer configuration based on wg configuration in above post, some notes:
- Address in wg config is Allowed Address in ROS wg peer config
- Endpoint shuld be Xray container IP and Endpoint Port Xray tunnel port (12884 in example)
- AllowedIPs from wg config must be handled with routing rules in ROS (connection to Xray server IP must be excluded from routing over wg)

add firewall rule to allow ROS wg peer connection to Xray container IP/tunnel port

add routing rules in ROS - assuming you want internet connections to be routed over this created wg peer - seek topics on this forum how to setup internet connection routing over wg with some notes:
- connections to Xray server IP must be excluded from routing over wg and must be always over WAN gateway (direct connection) because wg is tunneled over it
- if FQDN is used in for connection to Xray server then DNS server used by Xray for resolving (DoH 1.1.1.1 in my config example, can be any public DNS) must be also excluded for routing over wg (same as Xray server IP because Xray needs to resolve IP before wg connection is established), be careful how this rule is setup to avoid leaking connection to DNS over WAN from other IPs, connections needs to be routed only for container IP

dcavni · Sat Nov 02, 2024 6:54 pm

Thank you for taking your time to write this. I will start with this and try to make something work.

Does anyone know if routing over Zerotier works from Russia to EU?

anav · Sat Nov 02, 2024 9:01 pm

Much better just to move to Europe

No idea!

dcavni · Sun Nov 03, 2024 12:37 pm

That is for sure. I'm trying to help someone who will move to Russia for 4 years due to work and he would like to watch home television there. And this is quite problematic if none of the VPNs work.

dcavni · Fri Nov 29, 2024 10:49 pm

Unfortunately I don't have ROS device or CHR running on remote site, to do it in local CHR is a bit complicated because I need to create some routing rules on host computer to test routing over CHR running locally, don't have time to play with now...
I can give some tips related to site-to-site client side configuration:
add Xray container and put client config json at same name and path mentioned as for server setup

create ROS wireguard client peer configuration based on wg configuration in above post, some notes:
Address in wg config is Allowed Address in ROS wg peer config

Endpoint shuld be Xray container IP and Endpoint Port Xray tunnel port (12884 in example)

AllowedIPs from wg config must be handled with routing rules in ROS (connection to Xray server IP must be excluded from routing over wg)

add firewall rule to allow ROS wg peer connection to Xray container IP/tunnel port

add routing rules in ROS - assuming you want internet connections to be routed over this created wg peer - seek topics on this forum how to setup internet connection routing over wg with some notes:
connections to Xray server IP must be excluded from routing over wg and must be always over WAN gateway (direct connection) because wg is tunneled over it

if FQDN is used in for connection to Xray server then DNS server used by Xray for resolving (DoH 1.1.1.1 in my config example, can be any public DNS) must be also excluded for routing over wg (same as Xray server IP because Xray needs to resolve IP before wg connection is established), be careful how this rule is setup to avoid leaking connection to DNS over WAN from other IPs, connections needs to be routed only for container IP

Finaly found a little time to check this.
Is there any way to check if Xray client is connected to the Xray server from shell inside the container? For test i just used default configuration from sources you mentioned and only changed endpoint.

optio · Sat Nov 30, 2024 2:47 am

If you did not set keys and client ids I doubt it works, but you can install curl inside client container to test over xray socks proxy:

# apk uppdate
# apk install curl
# curl -vvv -x socks5://127.0.0.1:1080 https://www.google.com

Also you could temporary setup file logging in xray configuration on both sides while testing to some location in container and examine logs, see https://xtls.github.io/en/config/log.html

dcavni · Sat Nov 30, 2024 11:42 am

Well i guess i failed. I used this config (only changed hostname:443) and apparently i did something wrong in the config:
https://computerscot.github.io/wireguard-over-xray.html

curl -vvv -x socks5://127.0.0.1:1080 https://www.google.com
09:32:28.767893 [0-x] == Info: [READ] client_reset, clear readers
09:32:28.774195 [0-0] == Info: [HTTPS-CONNECT] added
09:32:28.778786 [0-0] == Info: [HTTPS-CONNECT] connect, init
09:32:28.784225 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
09:32:28.790230 [0-0] == Info:   Trying 127.0.0.1:1080...
09:32:28.791491 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
09:32:28.792638 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:32:28.793827 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
09:32:28.794908 [0-0] == Info: connect to 127.0.0.1 port 1080 from 127.0.0.1 port 39890 failed: Connection refused
09:32:28.796788 [0-0] == Info: Failed to connect to 127.0.0.1 port 1080 after 26 ms: Could not connect to server
09:32:28.798564 [0-0] == Info: [HTTPS-CONNECT] connect, all failed
09:32:28.799608 [0-0] == Info: [HTTPS-CONNECT] connect -> 7, done=0
09:32:28.800444 [0-0] == Info: [WRITE] cw-out done
09:32:28.800879 [0-0] == Info: closing connection #0
09:32:28.801320 [0-0] == Info: [HTTPS-CONNECT] close
09:32:28.801752 [0-0] == Info: [SETUP] close
09:32:28.802126 [0-0] == Info: [SETUP] destroy
09:32:28.802509 [0-0] == Info: [HTTPS-CONNECT] destroy
curl: (7) Failed to connect to 127.0.0.1 port 1080 after 26 ms: Could not connect to ser

Edit:

Now i added this to inbounds:

	{
            "listen": "127.0.0.1",
            "port": 1080,
            "protocol": "socks",
            "settings": {
                "udp": true
            }
        },

and the output now is a bunch of stuff in log, that i don't realy understand but i'm guessing, that the tunnel is working. In acess.log i found this:

 2024/11/30 18:05:57 from tcp:127.0.0.1:39920 accepted tcp:142.251.39.68:443 [proxy]

This is just part of the output:

0000: ...J...F0D. i.x....4..-.?.-...h..voN?....DD.. .....UfJ..,.D..O..
0040: -.=.R. s..H...
10:05:57.488608 [0-0] == Info: TLSv1.3 (IN), TLS handshake, Finished (20):
10:05:57.488907 [0-0] <= Recv SSL data, 52 bytes (0x34)
0000: ...0.i$...[.P.[."n..C.B8.lpu...BJ.u....K....uo.3...W
10:05:57.489649 [0-0] => Send SSL data, 5 bytes (0x5)
0000: .....
10:05:57.489927 [0-0] == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
10:05:57.490275 [0-0] => Send SSL data, 1 bytes (0x1)
0000: .
10:05:57.490688 [0-0] => Send SSL data, 5 bytes (0x5)
0000: ....E
10:05:57.490946 [0-0] => Send SSL data, 1 bytes (0x1)
0000: .
10:05:57.491188 [0-0] == Info: TLSv1.3 (OUT), TLS handshake, Finished (20):
10:05:57.491471 [0-0] => Send SSL data, 52 bytes (0x34)
0000: ...0.&I....uh.ql...cd.i^... .......E.*.(+Z.d.....u.T
10:05:57.492026 [0-0] == Info: [SSL] ossl_bio_cf_out_write(len=80) -> 80, err=0
10:05:57.492468 [0-0] == Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
10:05:57.492890 [0-0] == Info: ALPN: server accepted h2
10:05:57.493106 [0-0] == Info: Server certificate:
10:05:57.493314 [0-0] == Info:  subject: CN=www.google.com
10:05:57.493547 [0-0] == Info:  start date: Oct 21 08:38:45 2024 GMT
10:05:57.493805 [0-0] == Info:  expire date: Jan 13 08:38:44 2025 GMT
10:05:57.494087 [0-0] == Info:  subjectAltName: host "www.google.com" matched cert's "www.google.com"
10:05:57.494485 [0-0] == Info:  issuer: C=US; O=Google Trust Services; CN=WR2
10:05:57.494780 [0-0] == Info:  SSL certificate verify ok.
10:05:57.495017 [0-0] == Info:   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
10:05:57.495560 [0-0] == Info:   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
10:05:57.496070 [0-0] == Info:   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
10:05:57.496579 [0-0] == Info: [SSL] cf_connect() -> 0, done=1
10:05:57.496821 [0-0] == Info: [HTTPS-CONNECT] connect+handshake h21: 1173ms, 1st data: 5ms
10:05:57.497204 [0-0] == Info: [HTTP/2] [0] created h2 session
10:05:57.497472 [0-0] == Info: [HTTP/2] [0] -> FRAME[SETTINGS, len=18]
10:05:57.497742 [0-0] == Info: [HTTP/2] [0] -> FRAME[WINDOW_UPDATE, incr=1048510465]
10:05:57.498062 [0-0] == Info: [HTTP/2] cf_connect() -> 0, 1, 
10:05:57.498330 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=1
10:05:57.498602 [0-0] == Info: Connected to 127.0.0.1 (127.0.0.1) port 1080
10:05:57.498886 [0-0] == Info: using HTTP/2
10:05:57.499105 [0-0] == Info: [HTTP/2] [1] OPENED stream for https://www.google.com/
10:05:57.499430 [0-0] == Info: [HTTP/2] [1] [:method: GET]
10:05:57.499652 [0-0] == Info: [HTTP/2] [1] [:scheme: https]
10:05:57.499881 [0-0] == Info: [HTTP/2] [1] [:authority: www.google.com]
10:05:57.500170 [0-0] == Info: [HTTP/2] [1] [:path: /]
10:05:57.500377 [0-0] == Info: [HTTP/2] [1] [user-agent: curl/8.11.0]
10:05:57.500637 [0-0] == Info: [HTTP/2] [1] [accept: */*]
10:05:57.500856 [0-0] == Info: [HTTP/2] [1] submit -> 76, 0
10:05:57.501119 [0-0] == Info: [HTTP/2] [1] -> FRAME[HEADERS, len=31, hend=1, eos=1]
10:05:57.501481 [0-0] => Send SSL data, 5 bytes (0x5)
0000: ....y
10:05:57.501730 [0-0] => Send SSL data, 1 bytes (0x1)
0000: .
10:05:57.502028 [0-0] == Info: [SSL] ossl_bio_cf_out_write(len=126) -> 126, err=0
10:05:57.502286 [0-0] == Info: [HTTP/2] [0] egress: wrote 104 bytes
10:05:57.502608 [0-0] == Info: [HTTP/2] [1] cf_send(len=76) -> 76, 0, eos=1, h2 windows 65535-65535 (stream-conn), buffers 0-0 (stream-conn)
10:05:57.503134 [0-0] => Send header, 76 bytes (0x4c)
0000: GET / HTTP/2
000e: Host: www.google.com
0024: User-Agent: curl/8.11.0
003d: Accept: */*
004a: 
10:05:57.503843 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1^C

Now i just have to figure out how to put wireguard on top of all this.

On client Mikrotik i added new wireguard interface (MTU 1300) with IP 10.20.20.2/24 listenning on 51822 and a peer with endpoint 127.0.0.1:51822 (i used this port, because 51820 is already occupied. I fixed port number in config.json also).

On server Mikrotik i added new wireguard interface (MTU 1300) with IP 10.20.20.1/24 listening on 51822 and a peer with Allowed Adress 10.20.20.2/32

Still nothing happens. Can you see what did i miss from my settings?

How to enter this rule: "Xray container has access on input chain for UDP 12884 (WG port) for establishing connection to ROS WG" ?

optio · Sat Nov 30, 2024 4:19 pm

First change "dokodemo-door" protocol config on client side - this is tunneling config where you need to setup tunnel listening port and to where on other end (server side) connection (WG IP and port) needs to be established, set "listen" to address of any interface in container - "0.0.0.0", in my config is set to "127.0.0.1" because I'm running xray and WG client localy on computer, not in container. Then, "settings"->"address" and "settings"->"port" must be set to IP and port of WG peer on server side (responder), set to address of server side xray container subnet gw (router IP in subnet) and port to where WG is listening on server side. Also in client side WG config endpoint address and port must be xray client container ip and port value of "dokodemo-door"->"port" setting - on this port xray is listening for tunnel conection.

How to enter this rule: "Xray container has access on input chain for UDP 12884 (WG port) for establishing connection to ROS WG" ?

For this I'm referring on server side where xray container must be able to connect to its router IP and WG port (for tunnel settings in dokodemo-door mentioned above), depends how your rules are currently made, is curently container isolated or not, etc... Maybe connection already works, try it, if not, you can try with rule on server side:

/ip/firewall/filter add action=accept chain=input dst-port=<WG_LISTEN_PORT> protocol=udp src-address=<XRAY_SERVER_CONTAINER_IP>

above last "defconf: drop all..." rule and below "defconf: drop invalid.." input rules if you have "defconf" rules.
For client side, since client xray is also in container and WG client is actually ROS WG peer (initiator), WG endpoint connection to xray client container IP and listening tunel port must be alowed if container is isolated for connections from router. If ping to container IP from router is responding than it is probably allowed, all depends on your current rules...

dcavni · Sat Nov 30, 2024 5:00 pm

So isn't dokodemo-door configuration ok for my use case, where Wireguard client and Wireguard server are both on Mikrotik devices and also XRAY containers are on Mikrotik devices?

Ok, so first i had to make a working wireguard config over regular wan connection and that is working now.

Then i changed endpoint adress on my wireguard peer to XRAY container IP and port number set in the client config.json

Containers are not isolated, i can acess them from everywhere.

Now i will try to implement those things you mentioned. It seems a bit complicated to me

I'm attaching current client config and server config file if you can take a look at it:

Client:

{
    "log": {
		"error": "/var/log/Xray/error.log",
		"access": "/var/log/Xray/access.log",
        "loglevel": "debug"
    },
	"dns": {
        "servers": [
            {
                "address": "https://1.1.1.1/dns-query",
                "skipFallback": true,
                "queryStrategy": "UseIPv4"
            }
        ]
    },
    "routing": {
        "rules": [
            {
                "ip": [
                    "1.1.1.1"
                ],
                "outboundTag": "direct"
            }

        ]
    },
	"inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1080,
            "protocol": "socks",
            "settings": {
                "udp": true
            }
        },
		{
            "listen":"0.0.0.0",
            "port": 51822,
            "protocol":"dokodemo-door",
            "settings":{
                "address":"10.20.20.1",
                "port":51822,
                "network":"udp"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "*.sn.mynetname.net",
                        "port": 443,
                        "users": [
                            {
                                "id": "3b5390c5-52a2-472d-8dc2-103ef508be6c",
                                "encryption": "none",
                                "flow": ""
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "h2",
                "security": "reality",
                "realitySettings": {
                    "show": false,
                    "fingerprint": "chrome",
                    "serverName": "www.microsoft.com",
                    "publicKey": "eZfl07Tg9UII29GaS23QXqB15aqrJ4Khm0vKJIcaMCo",
                    "shortId": "77c2358dc476ae9e", 
                    "spiderX": ""
                }
            },
            "tag": "proxy"
        }
    ]
}

10.20.20.1 is the IP of the wireguard interface on server and 51822 is port on the wireguard server.

Server:

{
    "log": {
		"error": "/var/log/xray/error.log",
		"access": "/var/log/xray/access.log",
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "3b5390c5-52a2-472d-8dc2-103ef508be6c",
                        "flow": ""
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "h2",
                "security": "reality",
                "realitySettings": {
                    "show": false,
                    "dest": "www.microsoft.com:443",
                    "xver": 0,
                    "serverNames": [ 
                        "www.microsoft.com"
                    ],
                    "privateKey": "QNraK6EdxPNOzfbL2G1BTl_OeMSxm49H5vps2qzQ3E0",
                    "shortIds": [ 
                        "77c2358dc476ae9e"
                    ]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

I have to take a little rest from this, my head hurts when i just look at config file

Feel free to edit current files and attach them here, if you can find some time.

I will try to continue in the evening.

Thank you for your help.

Edit: Configuration fixed to a working state.

optio · Sat Nov 30, 2024 5:16 pm

Chenge "listen":"127.0.0.1" to "listen":"0.0.0.0" for "dokodemo-door" protocol as mentioned, you can also for "socks" if you want to use xray sock server from network. 127.0.0.1 is localhost interface address it cannot be accessed outside system (container). 0.0.0.0 address is alias for any interface address and service port will listen on all interfaces available on system. Other settings seems ok at first look.

dcavni · Sat Nov 30, 2024 5:48 pm

Whoa... It works

i just changed listen adress to 0.0.0.0 and Wireguard started to work.

Now i went to extremes and put EOIP on top of it.

23 Mbps DL / 31 Mbps UL. Enough for what it's needed.

i will fix previusly uploaded configs if anyone would need it.

Thank you very very much.

dcavni · Sun Dec 15, 2024 6:43 pm

I tried to add this container to another device and encountered an error. Probably updated container. Any idea what needs to be changed in configuration?

Failed to start: main: failed to load config files: [/etc/xray/config.json] > common/errors: The feature HTTP transport (without header padding, etc.) has been removed and migrated to XHTTP stream-one H2 & H3. Please update your config(s) according to release note and documentation.

optio · Mon Dec 16, 2024 12:04 pm

I didn't yet updated to latest version so I'm not familiar with issue, see in release notes where XHTTP is mentioned and link to its github issue, there is a config example as I see in issue maybe it helps.

dcavni · Mon Dec 16, 2024 1:37 pm

For now i solved the issue with installing older version. If you will do upgrade at one point please write here, what has changed in the config. It's still a bit unknown teritory for me.

Thank you

optio · Wed Dec 18, 2024 8:29 pm

Don't have mentioned issue after upgrading Xray container for server side on ROS to version 24.12.15

# xray --version
Xray 24.12.15 (Xray, Penetrates Everything.) Custom (go1.23.4 linux/arm)
A unified platform for anti-censorship.

still my client version on Mac is older, 1.8.24, MacPorts package is slower on updates for it, but it is not that old as it seems by version number (https://github.com/XTLS/Xray-core/tags?after=v24.9.16, they reversed version numbers after 1.8.24, idk why..., but it still all works with same configuration on both sides.

Also, I think it is enough of hijacking this topic, better open new one for Xray in ROS container in "3rd party tools" section, since this conversation is gone OT.

Amm0 · Wed Dec 18, 2024 8:42 pm

Also, I think it is enough of hijacking this topic, better open new one for Xray in ROS container in "3rd party tools" section, since this conversation is gone OT.

Or Mikrotik just add AmneziaWG and/or XRay containers to docs as examples and to test/fix /container support for them better. There are several threads on this but none are clear/"cookie cutter"... while there are major problems with using plain WG (and other proxy/etc approaches) in certain countries.

dcavni · Wed Dec 18, 2024 8:49 pm

This could also be done. It's a good thing, considering how much some authorities wish to censor available informations. There are many people who search for uncensored informations, but there is also many more of those, who have no idea how to achieve working Amnezia or Xray on Mikrotik, to get to those informations.

optio · Wed Dec 18, 2024 9:06 pm

Also there are different approaches for setup Xray, like using some tun2socks solution and adding routes for such interface inside container (viewtopic.php?p=1105243); or like example from this topic with tunneled WG using unmodified Xray container which is easier to maintain but adds some latency.

Who is online