Each uses OpenVPN, which is a much more secure protocol than L2TP or PPTP, and click for info they tend store records of connection timestamps, which can be something many other VPNs do. Secureness is a big area of concern for some VPN users, and AirVPN has some of the best protections.
However, Wireshark on the mobile device shows no returning packets.There’s more to AirVPN than satisfies the eye Maybe this use case is too complicated for OPNsense.Įdit: It seems that the packets are not showing up in the interface logs, because they are handled by the system rule "let out anything by the firewall host itself". No clue, what's going on there.Īnd now the response packets have also stopped without a clear connection to anything I'm doing. And of course the mobile still says the handshake could not be completed. I have rules in place on that interface to allow incoming packets, outgoing packets and block the rest. However, the log files show nothing at all for the WAN_AirVPN1 interface (except for the very first packet coming from the mobile device).
This happened with an accompanying log entry indicating that the outbound nat rule was applied. 23674: UDP, length 92Īnd sometimes the response had the WAN_AirVPN address as response: 23:25:55.030440 IP. Now I had the following output in my tcpdump on the AirVPN link with a response with the WAN address as source: 23:26:41.309072 IP. I have now (after discovering the packets on the WAN interface) added an outgoing NAT rule: Interface: WAN Unfortunately I already have the block+log rule on every interface, e.g. So, for some reason it seems the answers from the Wireguard server are not going back to the client, and I have no idea why.Īlso, is there a way to debug the Wireguard server so I can see if and where it is sending data?įirst of all, thanks for your continued help. Tcpdump shows no traffic at all on the wg0 interface. The 'transfer' numbers are increasing with each new handshake attempt from the client, but the handshake is never completed. Transfer: 87.59KiB received, 54.45 KiB sent Listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytesĠ0:44:34.929731 IP xx.xx.xx.xx.15697 > (AirVPN1 address).55555: UDP, length 148Īnd I see one (and only one) log message for the NATed package: Interface: WAN_AirVPN1īut the wireguard "List Configuration" shows only: peer:
#AIRVPN CANNOT CONNECT ANY PORTS FULL#
Tcpdump: verbose output suppressed, use -v or -vv for full protocol decode Now when I try to connect from the outside, I see that packets are coming in over the AirVPN connection: # tcpdump -i ovpnc2 -n The incoming packets are NATed in OPNSense: NAT:Port ForwardĪnd I allow traffic to go from WAN_AirVPN1 to the Wireguard tunnel network: Firewall:Rules:WAN_AirVPN1ĭescription: OpenVPN: Allow incoming Wireguard However, when I disable WiFi on the phone and set the peer address on the phone to :55555, no handshake is completed.
#AIRVPN CANNOT CONNECT ANY PORTS PLUS#
Also, I have setup rules on the WireGuard interface to allow traffic to my other VLANs and the WAN, plus an outgoing NAT rule, and I can access everything from the mobile device. When my phone is in my WLAN and I set it up to connect directly to 10.8.4.1, it works fine, so I believe the Wireguard configuration itself is correct. To test the wireguard server locally, I have allowed UDP port 55555 from my internal WLAN to the Wireguard server. These match the settings on my mobile device. The Wireguard Client (Endpoint): Enabled: (checked) I have configured firewall aliases WG_SERVER: 10.8.4.1 I have setup a Wireguard Server: Enabled: (checked) So far I have configured three AirVPN clients on OPNSense (using the excellent tutorials on ) and they are working as expected for outgoing traffic. Mobile Device -> AirVPN -> OpenVPN Client on OPNSense -> Wireguard Server In order to be able to connect to my home network from the outside, I have setup an AirVPN VPN that can forward ports over the VPN into my home network and I want to reach a Wireguard server in my network.
I have a DSLite connection at home, so no public reachable IPv4 address.
0 kommentar(er)
