Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP
Home › Forums › Conduit: AEP Model › Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP
- This topic has 10 replies, 2 voices, and was last updated 6 years, 10 months ago by Jeff Hatch.
-
AuthorPosts
-
January 15, 2018 at 10:36 am #22328Albert BeukmanParticipant
Summary
I cannot access any of the configuration interfaces through the WAN static IP. Remote Access Management is enabled for all WAN config interfaces. Copied static IP from Device Information (Home) while LAN page is open to prevent finger trouble. Issue seems limited to HTTP and SSH ports as other protocol and ports allow traffic through.Any feedback on what I can try would be appreciated.
Detail
* Confirmed PPP link up and good signal.
* 2-way Comms with LoRa units through public IP OK.
* Ping WAN interface from my PC OK.
* LAN access OK.
* SIM provisioning setup identical to operational 210-LVW2 models.
* SSH fail.
* HTTP Fail.
* HTTP from cell phone (outside office LAN) Fail
* Redirect to HTTPS has no effect.
* Node-red HTTP UI fail.Following up with cellular service provider as well.
January 15, 2018 at 11:06 am #22330Jeff HatchKeymasterAlbert,
Have you enabled access via WAN for HTTPS and SSH on the Conduit? Under Administartion->Access Configuration there are Web Server and SSH panes where you can enable via HTTPS and WAN.
Jeff
January 15, 2018 at 11:20 am #22331Albert BeukmanParticipantHi Jeff;
Thanks for the response. Yes, my apologies for not being clearer; this is what I meant with “Remote Access Management is enabled for all WAN config interfaces” and “Redirect to HTTPS has no effect”.
I.e. I have tried accessing the HTTP UI with the permutations shown below with “Via WAN” ticked under Administration->Access Configuration for the following.
* Web-Server – HTTPS.
* SSH.
* ICMP.
* Node-Red.Permutation 1: HTTP Redirect to HTTPS “Via WAN” ticked. FAIL.
Permutation 2: HTTP Redirect to HTTPS “Via WAN” not ticked. FAIL.The Detail section in my original post holds for both permutations above.
Kind regards,
AlbertJanuary 15, 2018 at 12:30 pm #22333Jeff HatchKeymasterAlbert,
Thank you for clarifying. I definitely recommend talking to the provider first to see what they are allowing for incoming traffic. Then proceed from there.
Jeff
January 15, 2018 at 3:52 pm #22343Albert BeukmanParticipantSpoke with cellular service provider.
It is a public, static IP. There are no restrictions on their side on this line. They even performed a network reset, forcing the device to register again (at which time I did a power-on reset for good measure). This had no effect and I was able to recreate my original results.
* Confirmed PPP link up and good signal.
* UDP traffic on custom ports OK.
* Ping from my PC OK.
* LAN access OK.
* HTTP fail.
* HTTP from cell phone fail.
* HTTP to Node-Red UI fail.
* SSH fail.Please advise.
January 16, 2018 at 8:22 am #22346Jeff HatchKeymasterAlbert,
Please file a portal case at support.multitech.com. They will be able to give you more dedicated help.
Jeff
January 16, 2018 at 10:10 am #22351Albert BeukmanParticipantDone. Thanks Jeff.
Kind regards.
January 18, 2018 at 1:59 pm #22393Albert BeukmanParticipantThis seems to be a SIM issue. Suspect issue with remote terminated connections.
I pulled a known good SIM from the field.
* The known good SIM allows HTTP connections on all 3 devices tested (2x 210Av1.3.2; 1x 247A v1.4.3).
* The recently provisioned SIM does not allow HTTP connections on any of the devices tested.Waiting to hear back from service provider for specific feedback on what is wrong with this SIM and how to prevent it in the future.
January 18, 2018 at 3:28 pm #22397Jeff HatchKeymasterAlbert,
Happy to hear that you are making progress as I was stumped as to what may be going on on the Conduit end. Hopefully the provider can get you a solution. Let us know if you need any more help.
Jeff
January 24, 2018 at 8:41 pm #22477Albert BeukmanParticipantFinally got to the bottom of this.
Suspect certain ISPs block remote terminated connections of certain protocols (HTTP and SSH in this case) for certain IP ranges. The public static IP block the mobile ISP assigned in the last instance seemed to have been blocked by at least T-mobile and AT&T.
GUI accessibility tests with IP assigned in the last instance.
* Verizon. OK
* Comcast. OK
* T-Mobile. Fail
* AT&T. FailKnown good SIM mentioned above succeeded in all instances.
ISP allocated a new IP address in a different subnet, after which the GUI was accessible on the public static IP on at least Verizon, Comcast and AT&T.
Hope this helps someone.
Kind regards.
January 25, 2018 at 7:41 am #22479Jeff HatchKeymasterAlbert,
Thank you for sharing what you found. This is excellent information for people having similar problems.
Jeff
-
AuthorPosts
- You must be logged in to reply to this topic.