- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Multi-homed R80.40 AWS AMIs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Multi-homed R80.40 AWS AMIs
Hi.
Would appreciate your guidance on the following scenario.
I'm trying to deploy a Securtity Management and a Gateway in an AWS VPC. My preferred solution would be to have both instances multi-homed in both private and public subnets, where managin server<->gateway traffic happened on the private subnet, and management, at least for the time being, was done though the public subnet from public internet addresses.
I believe that for CME/self-discovery, instances will try to use eth0, therefore I made eth0 the interfaces on the private subnet and eth1 is on the public subnet.
I've added the default route for the public subnet .1 address, but then got into the problem of not being able to access the management HTTS UI or SSH. If we set aside any other potential mistakes that I'm making in AWS config, what is the config_system parameters (or others), that I need to change to have 22/443 bounded in eth1 ? To make it clear, if I change the order of network interfaces and make eth0 the public, I can access them fine.
Already in the are of trying things auto, already run "set management interface eth1" on the user data script, but didn't seem to help...
Thanks
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That said, I haven't tried firing up R80.40 in AWS yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That said, I haven't tried firing up R80.40 in AWS yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You're right. I remembered to check netstat the ports on a working scenario and saw the *:443 so had to work-back the problem from there.... It was another problem. Thanks for the reply.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content