Guys,
Confirmed as well. My observations are this. I have this router box actually on the internet, it was up and managed on the internet from a conductor on the internet just through the linux interface. This is my head-end router. This was a clean router, no other configs, no SVR, nothing other than the conductor and one router on-net talking. This is what I did next.
- Got into the router via the conductor,
- created a WAN device on PCI 2,
- created an interface 'eth2'
- Gave it an ip address and gateway etc.
- set the 'conductor' slider to true,
- set source-nat on,
- went into the 'authority' made sure the IP address of the conductor is in place (errors otherwise)
- Committed
Done, managed and on-net!
I Checked via a direct display monitor what ifconfig looks like now, no enp2s0 on the router anymore (good), KNI128 is not there (oh!), this is a bit of a surprise having done it the old way. However via conductor a service _conductor_ and service policy, service route have been added. However the 'gateway in the service route is wrong, this may come back and create issues later (lets see). Also SSH via the internet does not work anymore into the linux console (good) because I disabled firewalld before. Firewalld is now active, so the device is secure on the linux side (no surprise there). Also in the 'service' the management ports have been added, 443, 4505 etc. have been added. The router seems to be secure!
marks out of 10 - I give it a '9'.
What happened to KNI128 as per the old method (care to comment)?
The gateway I got is the conductors address and not the actual network gateway. This may hurt later, I don't know yet.
Stephen
------------------------------
Stephen Lilley
------------------------------
Original Message:
Sent: 11-14-2019 12:14
From: Reid Stidolph
Subject: router on home network behind PAT not working
Hi , The document you linked is quite old, and the `conductor true` toggle effectively automates much of what it describes. By setting `conductor true` on an interface, you are declaring that the conductor address can be reached using the forwarding interface (typically a WAN in branch style deployments). When set, 128T will install a route to conductor in the host routing table (Linux) to send into the forwarding plane. Then it will auto-generate a conductor service+service-routes for the sessions to egress the forwarding plane at the selected interface.
------------------------------
- Reid
Original Message:
Sent: 11-13-2019 00:52
From: Stephen Lilley
Subject: router on home network behind PAT not working
Following on from this PAT issue because its a branch type application, I am intrigued as to what the slider button on the 'network interface', 'conductor' true/false and how that relates to this document if at all linked 'here' above How-To- Share Interface for Management and Data Planes.pdf ??
On face value based on the 'help' next to the GUI slider it says that interface can be used for conductor management. But the document above makes this all look a lot more complicated for a branch router to phone home than the plane old slider button implies should that interface be the WAN.
Stephen
------------------------------
Stephen Lilley
Original Message:
Sent: 11-11-2019 15:15
From: Justin Melloni
Subject: router on home network behind PAT not working
Hi ,
Thank you for your question!
So as you may know, the process that controls the Assets page is the automatedProvisioner. This is the process in charge of Zero-Touch Provisioning (ZTP) of your Routers by your Conductor. It uses SaltStack in the background which needs ports 4505 and 4506 open by any firewalls in-between your Routers and Conductors. SaltStack is a client to server DevOps tool, which means that the clients (Routers) send status messages to the server (Conductor). So in your case, the Conductor is showing "Connected" until messages from the Router time out then changes the status to "Disconnected." I imagine if you look at the automatedProvisioner.log file, you will see messages come out the Router but not make it to the Conductor.
Alright, so now onto the step for resolving this issue. So your last paragraph is correct that your lack of management ip address may be the issue. The 128T Router is going to send the traffic to the Conductor out the management interface by default. If you do not want to this, you need to do some configuration to tell "management" traffic to go out a forwarding plane. This article here can help you with that.
The Conductor will be listening on port 4505 and 4506 for Salt messages from the Routers. Also, if you look at /etc/salt/minion on the Router, you should see info under master: that points to the Conductor.
Let me know if this helps or if you have any other questions I can answer.
Thank you,
Justin
------------------------------
Justin Melloni
Technical Trainer
MA
9784305630
Original Message:
Sent: 11-06-2019 18:13
From: Alan Parr
Subject: router on home network behind PAT not working
I am testing a 128T router at home prior to shipping to customer site, and the router is not appearing a "running" on the conductor. If I make a change on the conductor, then restart the router, it picks up the changes and applies them to its configuration. However, on the Conductor Asset page, it shows a state of "connected" for a while, then a state of "disconnected". Likewise, the router CLI shows "disconnected" for the system connection.
My home connection is a flat network that shares a single public IP; the ISP router performs PAT to allow all traffic out using that single IP. Given that, it is not possible to access the router directly from the public internet; the router can only connect out, but return traffic on the same session should work fine. There is no firewall to block traffic.
Is this supported? Any suggestions on special configuration needed for this to work? Any suggestions on logs to review to see why it doesn't work?
Also, I have heard that the node needs a "management IP"; currently it only has an "outside-wan" IP and an "inside-lan" IP. I am accessing it via console. On the client site, it will not have any connections other than these. I am not sure if that's related or not.
thanks
Alan
------------------------------
Alan Parr
Network Engineer
774-235-0173
------------------------------