Do your neighbors use a single key - that will open your home, and theirs too?
The iPhone generates a key directly on the screen; and you generated one for the OpenWrt - so this should be straightforward. I think you're making this more difficult for yourself. You simply setup the iPhone and OpenWrt - after success with the iPhone, I would then setup the Android and OpenWrt.
If you haven't properly installed keys, that's why you don't have a connection. You're not going to get an error message.
Exactly!
at the moment i have 2 wireguard vpns configured in the app on ios - both end is same result as seen before (not working)
one that is a fresh scan of qr code - uses public key from openwrt and doesnt have peer configured
one that is what i have been working on throughout this thread
this one uses its own key pair that it generated.
the public key is also put in openwrt > interfaces > wireguard vpn > peer configuration > public key
I only activate 1 at a time of course
Also i only tried android tablet that once to double check; im not trying it every time.
Stop stop stop...
Why does your iPhone and peer possess the same public key!?!?!
To be clear, again:
generate Private Key on iPhone - it never leaves your phone
iPhone's Public Key goes to OpenWrt peer section
generate Private Key on OpenWrt - it never leaves your router
OpenWrt's Public Key goes in iPhone's peer section
Please note, you cannot reuse keys in the same setup!!!
wireguard app on ios
openwrt wireguard
latest log
2019-05-31 07:34:09.526344: [APP] startActivation: Entering (tunnel: skittles)
2019-05-31 07:34:09.527277: [APP] startActivation: Starting tunnel
2019-05-31 07:34:09.531432: [APP] startActivation: Success
2019-05-31 07:34:09.548686: [APP] Tunnel 'skittles' connection status changed to 'connecting'
2019-05-31 07:34:09.660818: [NET] App version: 0.0.20190319 (1); Go backend version: 0.0.20181222
2019-05-31 07:34:09.661143: [NET] Starting tunnel from the app
2019-05-31 07:34:14.532337: [APP] Status update notification timeout for tunnel 'skittles'. Tunnel status is now 'connecting'.
2019-05-31 07:34:14.954278: [NET] Tunnel interface is utun2
2019-05-31 07:34:14.955428: [NET] DNS64: mapped 69.131.49.158 to itself.
2019-05-31 07:34:14.958361: [NET] Attaching to interface
2019-05-31 07:34:14.963795: [NET] Routine: decryption worker - started
2019-05-31 07:34:14.967670: [NET] Routine: event worker - started
2019-05-31 07:34:14.972637: [NET] Routine: handshake worker - started
2019-05-31 07:34:14.977673: [NET] Routine: encryption worker - started
2019-05-31 07:34:14.982642: [NET] Routine: decryption worker - started
2019-05-31 07:34:14.984705: [NET] Routine: handshake worker - started
2019-05-31 07:34:14.989739: [NET] Routine: TUN reader - started
2019-05-31 07:34:14.992804: [NET] Routine: encryption worker - started
2019-05-31 07:34:14.995737: [NET] UAPI: Updating private key
2019-05-31 07:34:14.999310: [NET] UAPI: Removing all peers
2019-05-31 07:34:15.001670: [NET] UAPI: Transition to peer configuration
2019-05-31 07:34:15.005398: [NET] peer(dSdm…FtC4) - UAPI: Created
2019-05-31 07:34:15.007716: [NET] peer(dSdm…FtC4) - UAPI: Updating endpoint
2019-05-31 07:34:15.008522: [NET] peer(dSdm…FtC4) - UAPI: Updating persistent keepalive interval
2019-05-31 07:34:15.012286: [NET] Routine: receive incoming IPv4 - started
2019-05-31 07:34:15.016896: [NET] Routine: receive incoming IPv6 - started
2019-05-31 07:34:15.021822: [NET] UDP bind has been updated
2019-05-31 07:34:15.026805: [NET] peer(dSdm…FtC4) - Starting...
2019-05-31 07:34:15.030879: [NET] peer(dSdm…FtC4) - Routine: nonce worker - started
2019-05-31 07:34:15.035772: [NET] peer(dSdm…FtC4) - Routine: sequential receiver - started
2019-05-31 07:34:15.040756: [NET] peer(dSdm…FtC4) - Routine: sequential sender - started
2019-05-31 07:34:15.042930: [NET] Device started
2019-05-31 07:34:15.051336: [APP] Tunnel 'skittles' connection status changed to 'connected'
2019-05-31 07:34:15.060504: [NET] UAPI: Processing get operation
2019-05-31 07:34:16.054257: [NET] UAPI: Processing get operation
2019-05-31 07:34:17.054376: [NET] UAPI: Processing get operation
2019-05-31 07:34:18.054367: [NET] UAPI: Processing get operation
2019-05-31 07:34:19.053656: [NET] UAPI: Processing get operation
2019-05-31 07:34:19.532282: [APP] Status update notification timeout for tunnel 'skittles'. Tunnel status is now 'connected'.
2019-05-31 07:34:19.534032: [NET] UAPI: Processing get operation
2019-05-31 07:34:20.535386: [NET] UAPI: Processing get operation
2019-05-31 07:34:21.535222: [NET] UAPI: Processing get operation
2019-05-31 07:34:22.535410: [NET] UAPI: Processing get operation
2019-05-31 07:34:23.535389: [NET] UAPI: Processing get operation
2019-05-31 07:34:24.390973: [APP] startDeactivation: Tunnel: skittles
2019-05-31 07:34:24.396014: [APP] Tunnel 'skittles' connection status changed to 'disconnecting'
2019-05-31 07:34:24.888740: [NET] Network change detected with satisfied route and interface order [pdp_ip0]
2019-05-31 07:34:24.890740: [NET] DNS64: mapped 69.131.49.158 to itself.
2019-05-31 07:34:24.891038: [NET] UAPI: Transition to peer configuration
2019-05-31 07:34:24.894562: [NET] peer(dSdm…FtC4) - UAPI: Updating endpoint
2019-05-31 07:34:24.897533: [NET] Binding sockets to interface 3
2019-05-31 07:34:24.900516: [NET] Unable to bind v6 socket to interface:%!(EXTRA syscall.Errno=invalid argument)
2019-05-31 07:34:29.435511: [NET] Stopping tunnel
2019-05-31 07:34:29.435922: [NET] Device closing
2019-05-31 07:34:29.440318: [NET] Routine: event worker - stopped
2019-05-31 07:34:29.441421: [NET] Routine: TUN reader - stopped
2019-05-31 07:34:29.446097: [NET] Routine: receive incoming IPv4 - stopped
2019-05-31 07:34:29.450850: [NET] Routine: receive incoming IPv6 - stopped
2019-05-31 07:34:29.458577: [NET] peer(dSdm…FtC4) - Stopping...
2019-05-31 07:34:29.461415: [NET] peer(dSdm…FtC4) - Routine: sequential sender - stopped
2019-05-31 07:34:29.465857: [NET] peer(dSdm…FtC4) - Routine: nonce worker - stopped
2019-05-31 07:34:29.470893: [NET] Routine: encryption worker - stopped
2019-05-31 07:34:29.473009: [NET] Routine: handshake worker - stopped
2019-05-31 07:34:29.477847: [NET] Routine: encryption worker - stopped
2019-05-31 07:34:29.480779: [NET] Routine: handshake worker - stopped
2019-05-31 07:34:29.483777: [NET] Routine: decryption worker - stopped
2019-05-31 07:34:29.486763: [NET] peer(dSdm…FtC4) - Routine: sequential receiver - stopped
2019-05-31 07:34:29.490159: [NET] Routine: decryption worker - stopped
2019-05-31 07:34:29.492903: [NET] Interface closed
2019-05-31 07:34:29.506348: [APP] Tunnel 'skittles' connection status changed to 'disconnected'
@Owengerig , I really think your're making this hard on yourself.
in OpenWrt, there shouldn't be an endpoint host or port setting on a mobile peer (how would the device roam???)
I'm not sure what the log is for...
Are you sure your carrier permits you to send traffic to a UDP port <= 1024?
1 Like
lleachii:
in OpenWrt, there shouldn't be an endpoint host or port setting on a mobile peer (how would the device roam???)
I'm not sure what the log is for...
Are you sure your carrier permits you to send traffic to a UDP port <= 1024?
pretty sure isp does allow that traffic
i removed the endpoint host, that was from when we were trying to figure out the loopback address, and i forgot to remove it after.
i am willing to share my public key and ddns via messages if someone wants to
fyi if you guys want to give up too, thats fine, i understand
this has gone on a while and i dont mean to take up so much of your time
i also feel i should re-mention my verification steps (verifying it worked or not)
try to access 192.168.1.1 web interface for luci/openwrt via ios safari
try to access 192.168.1.1 smb to see if shares are available via PlayerXtreme app
and of course openwrt > interfaces - looking at rx tx of wireguard interface
trendy
May 31, 2019, 3:04pm
29
The configuration shared with you in this post is tested and working in my setup.
So apply it and stop messing with wireguard in Openwrt, like adding endpoints and ports.
Also we told you that you have the wrong address in the client, but you keep using 10.0.10.1/28 (which belongs to OpenWrt) instead of 10.0.10.2/28
2 Likes
This is a working config for me, I added the borrowed iPhone to this interface:
On OpenWrt:
# in /etc/config/network
config interface 'test_wireguard'
option proto 'wireguard'
option private_key '<pri_key_generated_on_OpenWrt>'
option listen_port '1200'
list addresses '172.3.3.1/29'
config wireguard_test_wireguard
option public_key '<pub_key_generated_on_iPhone>'
list allowed_ips '172.3.3.2/32'
# in /etc/config/firewall
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option name 'Wireguard_VPN'
option family 'ipv4'
option dest_port '1200'
On phone:
Device
Name - your choice
Private Key (generated)
Public key = <pub_key_generated_on_iPhone>
172.3.3.2/29
DNS Server 172.3.3.1
Peer setting
Public Key = <pub_key_calculated_from_OpenWrt_priv_key>
Allowed IPs 0.0.0.0/0
Endpoint = example.com:1200
2 Likes
thats what i have though
firewall.@rule[9]=rule
firewall.@rule[9].src='wan'
firewall.@rule[9].proto='udp'
firewall.@rule[9].target='ACCEPT'
firewall.@rule[9].name='Allow-wireguard'
firewall.@rule[9].dest_port='1200'
network.wireguardVPN=interface
network.wireguardVPN.proto='wireguard'
network.wireguardVPN.private_key='<pri_key_generated_on_OpenWrt>'
network.wireguardVPN.addresses='10.0.10.1/28'
network.wireguardVPN.listen_port='1200'
network.@wireguard_wireguardVPN[0]=wireguard_wireguardVPN
network.@wireguard_wireguardVPN[0].allowed_ips='10.0.10.2/32'
network.@wireguard_wireguardVPN[0].persistent_keepalive='25'
network.@wireguard_wireguardVPN[0].description='IOS peer'
network.@wireguard_wireguardVPN[0].public_key='<pub_key_generated_on_iPhone>'
network.@wireguard_wireguardVPN[1]=wireguard_wireguardVPN
i also verified it resolves the correct ip from the my ddns, as it shows the ip as soon as you hit activate in that same endpoint field
trendy
May 31, 2019, 3:30pm
32
That's much better now. Unless there is some mistake in the keys, it should work.
What puzzles me is that the iphone client uses public key for the interface. Not sure if it is typo or indeed you need to specify there the public key that iphone produced.
2 Likes
even when starting from scratch on wireguard app, you cannot input text into the public key, you need to hit generate pair
so as far as i can tell its suppose to be the iphones generated public key
2 Likes
Can you describe the procedure that you used to generate the Private and Public Keys?
1 Like
i followed the tutorial
created that wireguard directory, cd into it, then ran
wg genkey | tee privkey | wg pubkey > pubkey
then i just coppied the key to the interface, per
If you are using LuCI to configure WireGuard, it's enough to run “wg genkey” and copy the output into the field “Private Key”; The public key is then later shown in the LuCI interface under Status > WireGuard status.
1 Like
@Owengerig , per the thread below, if you've been using QR Codes, please attempt manually copying the OpenWrt public key to your iPhone. There might be a bug with the QR code generation.
Yes, and it does work if you do not define/create a peer (just the upper part with the private key). The QR Code was somewhat smaller if i reckon correctly and it passed the servers private/public key pair. That's probably not correct. The private key should never be exposed i guess. And as i added a peer the QR Code didn't work anymore (syntax error in peer).
No, not tried yet. Will test that next time.
Edit: 'reload' didn't help but 'restart' shows the new public key now on 'wg'.
1 Like
qr code makes the interface set to the same public key as openwrt has
but it seems that the way it should be is that you generate a priv/pub key pair on the app to use as your interface settings
but for peer settings on the ios app; this is where you use the public key of the server (openwrt)
cpunk
June 1, 2019, 1:20pm
38
(edited after reviewing the thread not on mobile and realizing the tunnel may not be coming up at all)
With the current configuration, can you ping the OpenWRT tunnel address from the iPhone?
Run this command via ssh to the server to see if a connection was established:
wg show
If so (remote peer has a last handshake entry), is there is any traffic received by your firewall rule? run:
iptables -L -v
Find your Wireguard firewall rule(s) in the output and see if there are any packets received to it. If not then there is something blocking UDP 1200. Either ISP or local. If so then make sure you have forwarding set up between wg and lan.
2 Likes
trendy
June 1, 2019, 10:30pm
39
Run also a tcpdump on the server to verify that packets from client really get to it.
tcpdump -i eth1.2 -vvn udp port 1200
2 Likes
OK, I have tested this QR Code thing.
It actually provides the entire config for the OpenWrt side, including peers and the OpenWrt's private key. This is not helpful to setup a peer device.
I would think it gives you the public key of the interface.
1 Like
Yes
cpunk:
wg show
resulted in :
root@OpenWrt:~# wg show
interface: wireguardVPN
I did create a port forward rule, but there was already a firewall rule allowing traffic on port 1200
root@OpenWrt:~# tcpdump -i eth1.2 -vvn udp port 1200
tcpdump: listening on eth1.2, link-type EN10MB (Ethernet), capture size 262144 bytes
05:34:18.636590 IP (tos 0x0, ttl 55, id 63707, offset 0, flags [none], proto UDP (17), length 176)
166.171.251.7.37533 > 69.131.49.158.1200: [udp sum ok] UDP, length 148
05:34:23.881231 IP (tos 0x0, ttl 55, id 62037, offset 0, flags [none], proto UDP (17), length 176)
166.171.251.7.37533 > 69.131.49.158.1200: [udp sum ok] UDP, length 148
05:34:29.098710 IP (tos 0x0, ttl 55, id 65161, offset 0, flags [none], proto UDP (17), length 176)
166.171.251.7.37533 > 69.131.49.158.1200: [udp sum ok] UDP, length 148
05:34:34.329892 IP (tos 0x0, ttl 55, id 20095, offset 0, flags [none], proto UDP (17), length 176)
166.171.251.7.37533 > 69.131.49.158.1200: [udp sum ok] UDP, length 148
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
I was surprised to see these packets, especially since the Wireguard interface still shows 0 for rx/tx