04-03-2017 04:38 AM
04-05-2017 10:38 AM
Not able to use NETv4_xxx groups in EdgeOS NAT rules.
04-11-2017 03:08 PM
As https://community.ubnt.com/t5/EdgeMAX/Known-Issues-of-EdgeMax-Series/m-p/1859460#M153239 hasn't been confirmed as bug yet
=>>ER-X : don't use firewall rules or QoS on eth ports under switch0 ! They apply fine....but on reboot, all eth ports will be dropped from the switch (really all) , making ER-X inaccessible from LAN
04-25-2017 10:01 AM
The following two threads set out the same issue.
This issue is a show stopper for us. Will revert all sites back to Zyxel USG50 (they do not exhibit this behaviour). Will check back here for progress.
05-03-2017 07:47 PM
This has been confirmed by UBNT: https://community.ubnt.com/t5/EdgeMAX/VPN-L2TP-IPSEC-not-connecting-to-one-WAN-link/m-p/1900960#M158...
If you have two PPPoE based WAN connections the VPN will only connect to one, even when the interface is not specified.
05-25-2017 08:04 AM
When configuring a GRE-Bridge as discribed in this configuration guide you need to reboot both devices to get the GRE tunnel up and working. The same applies to a GRE configuration change. Without a reboot it is not working and a packet captures shows:
00:51:25.786513 IP 82.xxx.xxx.xxx > 92.xxx.xxx.xxx: GREv0, length 96: IP 192.168.1.3.50842 > 192.168.31.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 00:51:25.806767 IP 82.xxx.xxx.xxx > 92.xxx.xxx.xxx: ICMP 92.xxx.xxx.xxx protocol 47 port 25944 unreachable, length 124
I've had this issue with versions: 1.8.0, 1.9.1 and 184.108.40.206. Haven't tested it with other versions.
05-25-2017 02:30 PM
IPsec performance issue (on 220.127.116.11 and most probably versions after 1.3.0):
- iperf-connection test without IPSec tunnel (direct WAN-WAN): line speed
- iperf-connection test on IPSec tunnel (WAN-WAN): +/- 10Mbit/s
I've read everyhting on this forums and i've tested changing MTU, MSS clamping, disabling offloading, but unfortunately nothing helps. Looking at the forum posts there are many more Ubiquiti customers with the same issue.
I hope Ubiquiti can find and fix this issue...
06-07-2017 08:35 PM - edited 06-07-2017 08:38 PM
Agreed, why hardcode a likely changing IP when the router manages the IP. Or fix the problem associated with using "any", which does not currently work.
How about a GUI option to allow dhcp-interface eth[n] in place of local-ip.
06-12-2017 12:44 AM - edited 08-14-2017 02:12 PM
Wait, the GUI and/or CLI saves a hardcoded IP that was obtained via DHCP?
In the GUI:
- Config Tree
- Peer URL/Name
Then set "dhcp-interface" to your external interface, such as eth0. Delete the hardcoded IP under local-address, assuming that you had entered a fixed IP in the GUI or from the command line. Preview and Save.
Your router now obtains the IP automatically from the dhcp interface. Don't forget that you manually set this because it will not appear anywhere under the dedicated VPN settings in the GUI. So yes, and I'm not sure why this isn't the default. Life saver for me because the "any" setting doesn't work.
06-13-2017 02:08 AM
EdgeMax-1-9-1-1-l2tpv3-Multicast-message-not-sent-in-tunnel seems also to be an inssue on the EdgeSeries,
I would be happy to know if there is a work around and if it has been reproduced in labs
I have tried to change the MTU without success to solve this issue
06-21-2017 03:58 AM
PPPoE connection drops, the folowing LCP request is shown in the logs looping indefinitely (always id=0x5):
Sent [LCP ConfReq id=0x5 <mru 1492> <magic 0x5e760a64>]
Issue highlighted here:
07-11-2017 08:33 AM
I cannot access https://community.ubnt.com/t5/EdgeMAX-Beta/DNSMASQ-stops-running-after-a-few-seconds/m-p/1768651 because of authorization failure and thus cannot verify is this about the same I found on my ERPro. My pull request to vyos which seems to incorporate the same problem in dhcpd-config.pl is here https://github.com/vyos/vyatta-cfg-dhcp-server/pull/12
Please be aware about that issue if not yet. I would love to see this perl script fixed in some next firmware releases so it needs not to be fixed by hand anymore. :-)