Suspend email no postpone button ?

[oskaratk]

Trying to test the suspension features.

Email to client goes out, but I don't see a postpone button in the email(s).

Also, on the walled garden pages I don't see a postpone, pay or similar button

In System-Billing-Suspension. postpone suspension is enabled and due date +suspension delay is passed

Am I missing something ?

Thanks

Oskar

[UBNT-Petr · Accepted solution]

Understood. So far, the client has only one chance how to postpone the suspension - on the suspension page. (which is inaccessible in case of https connections)

I agree we could improve this (although this situation shouldn't really happen to the "good customers" who are notified many times before the suspension is triggered)

Anyway, we will add the "postpone" button to other places as well: into the suspension email and into the client zone.

We will add this to our scope, I will try to squeeze it into 2.16

[UBNT-Petr]

@oskaratk the postpone button is shown on the suspension page only when the client is correctly detected by their IP (i.e. there is no NAT in between the client and the suspending router) and only when the router is correctly configured. Please refer to this guide: https://help.ubnt.com/hc/en-us/articles/220161007-UCRM-Setting-up-Network-Devices-Suspension-Feature

The postpone button in the email notification is not implemented yet but it's a good idea, we will look into it.

[oskaratk]

Thanks,

I got the IP matching and the test user is redirected to the personalized suspend page.

Can log into UCRM as well.

However the pay button in UCRM does not work. I am assuming something with my firewall rules on the Mikrotik is not right yet

Below is what I get in dev mode of firefox - looged in from the suspended IP vs logged in from an different IP.

Interestingly, coming from the blocked IP, I see a call to stripe - which is not what we use. We use PayPal

Any hints?

Thanks

Oskar

This first screenshot is when I log in as suspended client. From the IP of the suspended service (device).  The PayPal dialog does not come up

And this one if I come from a different IP. Everything works and I can pay

[scampbell55]

@ubnt-PETR  I'm working w/ Oskaratk on this (we are from the same company) so want to add some additional info.

I configured the firewall rules, proxy rules etc to make this work in our network, so I'm posting the details here.  Hopefully this will convince you that the nat, firewall and proxy configuration is correct but if you have specific questions/concerns let me know.  I have tested these rules extensively and I'm confident they are working as expected. 

Section I: NAT rule

[Mikrotik-router]] /ip firewall nat> print     
Flags: X - disabled, I - invalid, D - dynamic
<snip>
 1    chain=dstnat action=redirect to-addresses=proxy-IP to-ports=8080 protocol=tcp
      src-address-list=disconnected dst-port=80

Comment: Nat rule is port 80 only as transparent redirection of https/ssl does not work w/ out throwing an error to the customer browser.  This is a well known issue w/ attempts to transparently redirect or proxy https traffic.  Disconnected address list is the only item changed when a customer is to be disconnected for non-payment.  All other nat, firewall and proxy rules discussed below will not be modified.  The disconnected list is modified via Mikrotik API.

Section II. Firewall rules.

[Mikrotik-router]] /ip firewall filter> print                               
Flags: X - disabled, I - invalid, D - dynamic

Comment:   rules 0-6 removed as they are not relevant


 7    chain=disconnected protocol=icmp

 8    chain=disconnected protocol=udp dst-port=53

 9    chain=disconnected protocol=tcp dst-port=53

10    chain=disconnected protocol=tcp dst-port=80

Comment: Rules 7-10 are for disconnected clients to allow them access to ping/traceroute, dns anywhere and port 80 which is transparently redirected by the nat rule (above) to the proxy.

The proxy allows clear text http (port 80) to a few sites including the public and private ip of the CRM server.  Once connected to the crm server on port 80, the client receives a redirect to the public IP of the CRM server on port 443.  This is allowed by rule 11.  


11    chain=disconnected protocol=tcp dst-address=public-ip-crm

12    chain=disconnected protocol=tcp dst-address=private-ip-crm

Comment: Rules 11,12 allow the client to access the UBNT crm server on any port which is necessary for the client to see that they are suspended as well as take action on their account (e.g. click the make payment button).


13    chain=disconnected protocol=tcp src-port=22

14    chain=disconnected protocol=tcp src-port=80

15    chain=disconnected protocol=tcp src-port=443

16    chain=disconnected protocol=udp src-port=161

17    chain=disconnected protocol=tcp dst-address=ubnt-air-control-server


Comment: Rules 13-17 are admin/management traffic from the client device to Xbar7 trusted networks (this is all reply management/admin traffic).

18    chain=disconnected action=drop

Rule 18 is the drop rule.  All traffic not dealt w/ above is dropped.

19    chain=forward action=jump jump-target=disconnected src-address-list=disconnected

Comment: Rule 19 is puts traffic from the clients in the disconnected list into the jump chain which is processed in the above 7-18 rules.

Section III Proxy config:

Comment:  The transparent proxy is also on a Mikrotik device and the config is as follows:

[xb7@xb7-mc-rtr-1] /ip proxy access<SAFE> print detail
Flags: X - disabled
 0   dst-port=80 dst-host=www.ourisppage.com action=allow hits=9

Comment: This allows disconnected customers to connect to our main website.

 1   dst-port=80 dst-host=xb7-crm.ourisp.com action=allow hits=5

Comment:  this allows disconnected customers to connect our isp UBNT CRM server on port 80.  The CRM server redirects the customer to port 443 on the same server and this is allowed in firewall rule 12&13 as noted above.  This works, we have confirmed with extensive testing of test clients added to the disconnect IP address list.

 2   dst-port=80 action=deny redirect-to="xb7-crm.outisp.com:81/suspended-service" hits=427

 3   dst-port="" action=deny hits=0

One important point worth noting.  Obviously there is no whitelisting of the paypal (or stripe.com) payment service IPs in my above firewall rules.  While this could be done for stripe.com (it resolves to a single IP) it cannot be done for paypal.  See documentation from Paypal at: https://www.paypal.com/us/smarthelp/article/what-are-the-ip-addresses-for-live-paypal-servers-ts1056... Note that several of the necessary PayPal fqdns are commented that they are provided via 3rd party (what they mean is a CDN / content distribution network), are dynamic and therefore cannot be whitelisted.  

This presents an interesting problem which is that if the non-paying disconnect function is to work properly and allow payment, it is IMO necessary that the UBNT CRM server act as middle ware and itself initiate the connection to paypal on behalf of the customer, rather than redirect the customer via http to paypal.com.  I understand this will bring in some man-in-the-middle concerns, possibly some PCI compliance concerns, and certainly concerns regarding the customer cc/payment data stored (even if only in memory) on the CRM server, but I don't see how else UBNT can make this disconnected for non payment function, and yet allow payment work without an approach like that.  As noted earlier the redirect will fail because paypal cannot be whitelisted on the firewall.

Do you have any suggestions for us?

[UBNT-Petr]

My thoughts:

Not sure whether this the good approach. I assume your main goal is to allow suspended clients to process a payment and you do that by whitelisting the payment gateways IPs.
Note that there are several problems with that
- you may not be even able to detect the proper IP to be whitelisted and they can be changed very frequently
- your client may want to access other services to process the payment (e.g. email, bank account, etc) - which won't be whitelisted anyway
- the HTTPS issue: no matter what you do, you can affect the HTTPS connections

I still think the best way is to use and properly configure the existing features: suspension delay + enable clients to postpone the suspension for 1 day.
The suspension postponing should do the job. Feel free to discuss improvements in this field, like enable more days (and/or skip bank-holidays, etc)

[oskaratk]

@UBNT-Petr

thanks for your quick reply.

I believe we misunderstood how a suspended client is supposed to pay. Thanks for clarifying that.

Here is the culprit that led to the misunderstanding: "without entering client zone"

How is a client supposed to postpone his suspension?

In the moment when I login in as "regognized suspended client" , I see this, account overview and a pay button ( which does/cannot not work):

IMHO, the client sould see something like "service suspended, click here to lift (postpone) suspension for 24h". In the moment - as client - I cannot even see that my service is suspended.

Or, once the client hits the pay button, lift the suspension automatically for 24h and give that feedback to the client

As admin, I can see the client is suspended

Thanks

Oskar

[scampbell55]

@ubtn-Petr I agree w/ your suggestion, in fact I had basically concluded the same by the time I finished writing my previous post.  But I thought it worthwhile to go ahead and post to make sure we weren't missing something. 

As you suggest, let's focus on getting the remove suspend feature temporarily working correclty so the client can remove it to pay w/ out our needing to whitelist payment services.  To that point, I think Oskar has or will post shortly on how to make progress on that point.

[UBNT-Petr · Accepted solution]

Understood. So far, the client has only one chance how to postpone the suspension - on the suspension page. (which is inaccessible in case of https connections)

I agree we could improve this (although this situation shouldn't really happen to the "good customers" who are notified many times before the suspension is triggered)

Anyway, we will add the "postpone" button to other places as well: into the suspension email and into the client zone.

We will add this to our scope, I will try to squeeze it into 2.16