Reply
Senior Member
Posts: 4,268
Registered: ‎01-04-2017
Kudos: 593
Solutions: 205

Re: Known Issues of EdgeMax Series

Another possible bug, if you could please look at when you get a chance

https://community.ubnt.com/t5/EdgeMAX/QoS-ceiling/m-p/1808723#U1808723
Senior Member
Posts: 3,662
Registered: ‎05-15-2014
Kudos: 1281
Solutions: 257

Re: Known Issues of EdgeMax Series

Bug DNSMASQ dies when adding static-lease

...acknowledged as bug here https://community.ubnt.com/t5/EdgeMAX-Beta/Bug-DNSMASQ-dies-when-adding-static-lease/m-p/1808625#M19...

Senior Member
Posts: 3,662
Registered: ‎05-15-2014
Kudos: 1281
Solutions: 257

Re: Known Issues of EdgeMax Series

[ Edited ]

UBNT-Fenng wrote:

c) IPSEC only works with a single FQDN peer entry.

VPN with FQDN issues

https://community.ubnt.com/t5/EdgeMAX-Beta/BUG-1-8-0-FQDN-peer-for-IPSEC-site-to-site/m-p/1748166#M1...

  


I don't know exactly what the root issue is, but IPSec works with multiple FQDN entries with x509 (and likely with RSA too). I believe this issue is only exhibited when PSK is used.

 

Please review strongSwan ID Selectors and Identity Parsing. ...I have a feeling (needs proper testing) that some of the issue will go away once strongSwan is updated to more recent version (please consider the upgrade in next alpha/beta).

 

Here is the important part from strongSwan:

"When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded, so the ID used will be the IP address."

...

If the string begins with @ the type is set to FQDN and the encoding is the literal string after that prefix.
In versions before 5.0.0 this prefix prevents that a FQDN is resolved into an IP address (current versions don't automatically resolve FQDNs when parsing identities).

...

For all other strings an attempt at parsing them as IPv4 addresses is made (since 5.4.0 also as subnets and ranges,see above). If that fails the type is set to FQDN and the literal value is adopted as encoding (this is where domain names and simple names end up).

 

Emerging Member
Posts: 76
Registered: ‎09-16-2013
Kudos: 4

Re: Known Issues of EdgeMax Series

Web gui open crach bgp
Regular Member
Posts: 729
Registered: ‎11-06-2013
Kudos: 226
Solutions: 26

Re: Known Issues of EdgeMax Series


BranoB wrote:

 I don't know exactly what the root issue is, but IPSec works with multiple FQDN entries with x509 (and likely with RSA too). I believe this issue is only exhibited when PSK is used.

 

Please review strongSwan ID Selectors and Identity Parsing. ...I have a feeling (needs proper testing) that some of the issue will go away once strongSwan is updated to more recent version (please consider the upgrade in next alpha/beta).

 


Great, they need to update and include the ID when the GUI makes IPSEC VPN then. Simple to solve, why have they not done it since 1.7.0 or whenever it first cropped up?

 

Ubiquiti Employee
Posts: 185
Registered: ‎08-11-2016
Kudos: 31
Solutions: 3

Re: Known Issues of EdgeMax Series

We have compiled new StrongSwan. But we need test it before release it.

Would you like to help us do beta testing?

Senior Member
Posts: 3,662
Registered: ‎05-15-2014
Kudos: 1281
Solutions: 257

Re: Known Issues of EdgeMax Series

[ Edited ]

Is it the U5.5.2dr2/K3.10.14-UBNT that you sent me? That one is working fine for me for basic site-to-site tunnels with x509 and L2TP with PSK. I've not had a chance to test VTI nor GRE.

 

If you have newer package please send.

Ubiquiti Employee
Posts: 185
Registered: ‎08-11-2016
Kudos: 31
Solutions: 3

Re: Known Issues of EdgeMax Series

Yes. It is. Does it fixed this FQDN issue?

Senior Member
Posts: 3,662
Registered: ‎05-15-2014
Kudos: 1281
Solutions: 257

Re: Known Issues of EdgeMax Series

[ Edited ]

Well, all my 10 tunnels are on FQDN. FQDN definitely works with x509. Unfortunately I can't easily swap to PSK for testing as all tunnels are being used.

 

That said, I don't believe the FQDN issue is a bug, it's an inherent limitation from strongSwan due to: 

"When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded (decrypted), so the ID used will be the IP address."

 

So this is really mainly configuration issue. There are, IMO, only two ways to overcome this:

1) Manually via config insert selector "any"

or

2) Resolve FQDN to IP and put that as selector to the secrets file. But there would need to be a mechanism do dynamically update this selector once the IP has changed if it's dynamic.

 

Best solution is to use x509 or RSA or IKEv2 (not sure about the last one but the man page suggests only IKEv1 has this shortcoming).

Emerging Member
Posts: 46
Registered: ‎11-19-2015
Kudos: 5

Re: Known Issues of EdgeMax Series

[ Edited ]

IPSec issue. (no loadbalance)
(ERL as server and windows 10 as client)
Internet cable comes directly from ISP and is pluged in eth0 port. It's a Fixed IP. (however eth0 is configured as dhcp)


in v1.9.0
1 - vpn works
2 - reboot ERL
3 - can't connect do vpn
4 - change any vpn option in the config tree
5 - can connect to vpn.

 

in v1.9.1
1 - vpn works
2 - reboot ERL
3 - CAN connect
sundenly internet is gone because of ISP problems.
4 - reboot ERL
5- there is still no internet because ISP won't give your fixed IP that is also the IP of the vpn server specified in the configs
6 - internet comes back.
7 - CAN'T connect

 

Link of the ignored thread:

https://community.ubnt.com/t5/EdgeMAX/ERL-1-9-X-Can-t-connect-to-l2tp-ipsec-vpn-server-after-router/...

 

edit: linked thread updated with logs and command outputs

again, changing auto-net-exclude-wtv in config tree solves the issue until next reboot w/out internet occurs.

Veteran Member
Posts: 5,671
Registered: ‎03-24-2016
Kudos: 1519
Solutions: 650

Re: Known Issues of EdgeMax Series

EdgeRouter X Inter-VLAN routing issues

When using switch in vlan-aware mode, routing between switch0 and other vif interface isn't possible.

current workaround:  put switch0 config under switch0.1  (=vif1)

 

see, amongst others:

https://community.ubnt.com/t5/EdgeMAX/EdgeRouter-X-Inter-VLAN-routing-issues-How-I-solved-it/m-p/181...

New Member
Posts: 28
Registered: ‎01-21-2012
Kudos: 72

Re: Known Issues of EdgeMax Series

two wishes:

 

1. A more stable IPSec.

 

2. Although not acknowledged by UBNT people because was not able to reproduce the problem (another user not previously known to me with different set up and several tests, between the two stump with the same issue).

https://community.ubnt.com/t5/EdgeMAX/bfd-static-routes-and-internet-access/td-p/1701549

 

Problems with bfd when topology changes involving static, connected, and default routes.

 

I believe the same problem with routes may be related to some other scenarios.

Senior Member
Posts: 3,662
Registered: ‎05-15-2014
Kudos: 1281
Solutions: 257

Re: Known Issues of EdgeMax Series

New Member
Posts: 7
Registered: ‎10-14-2016
Kudos: 1

Re: Known Issues of EdgeMax Series

Hi UBNT-Fenng,

 

Thank you for your work for updated EdgeMax.

I have ERX and have issue about 2 about IPSEC.

 

  1. Support IPSEC (IPv4 over IPv6). Now I need to additonal GRE (IPv4 over IPv6) under 1.9.1, it works but complicated.
  2. Stable IPSEC support for IPv6. Current 1.9.1 suppots IPSEC (IPv6 over IPv6) but still have issue even without hardware offload ipsec like many error log as kernel level. With hardware offload, IPSEC tunnel (IPv6 over IPv6) itself is not built.

Regards,

Senior Member
Posts: 4,268
Registered: ‎01-04-2017
Kudos: 593
Solutions: 205
Emerging Member
Posts: 96
Registered: ‎07-07-2014
Kudos: 16
Solutions: 1

Re: Known Issues of EdgeMax Series

Can I also add the LDP bug identified here: https://community.ubnt.com/t5/EdgeMAX-Beta/ldp-cleaning-full-table-and-mpls-forwarding-table/m-p/183...

 

This seems like a show stopper for using MPLS/LDP in a production network?

New Member
Posts: 5
Registered: ‎02-15-2014

Re: Known Issues of EdgeMax Series

New Member
Posts: 15
Registered: ‎10-24-2016
Kudos: 5
Solutions: 1

Re: Known Issues of EdgeMax Series

[ Edited ]

This one was acknowledged as a bug:

https://community.ubnt.com/t5/EdgeMAX/BUG-IPv4-DHCP-IPv6-address-on-WAN-interface-dhclient-exit-hook...

It prevents dhcp hook scripts from being called as soon as an IPv6 address is set for the WAN interface.

Regular Member
Posts: 729
Registered: ‎11-06-2013
Kudos: 226
Solutions: 26

Re: Known Issues of EdgeMax Series


BranoB wrote:

Well, all my 10 tunnels are on FQDN. FQDN definitely works with x509. Unfortunately I can't easily swap to PSK for testing as all tunnels are being used.

 

That said, I don't believe the FQDN issue is a bug, it's an inherent limitation from strongSwan due to: 

"When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded (decrypted), so the ID used will be the IP address."

 

So this is really mainly configuration issue. There are, IMO, only two ways to overcome this:

1) Manually via config insert selector "any"

or

2) Resolve FQDN to IP and put that as selector to the secrets file. But there would need to be a mechanism do dynamically update this selector once the IP has changed if it's dynamic.

 

Best solution is to use x509 or RSA or IKEv2 (not sure about the last one but the man page suggests only IKEv1 has this shortcoming).


3) They add the Peer ID into the GUI

Veteran Member
Posts: 4,857
Registered: ‎07-03-2008
Kudos: 1469
Solutions: 119

Re: Known Issues of EdgeMax Series

How about a GUI option to allow dhcp-interface eth[n] in place of local-ip.

Reply