AWS Install, Failing to have Clients Ping to pfSense Interfaces (LAN/WAN)
-
For the past few days, I have been attempting to install pfSense onto the AWS cloud to provide a layer of protection and VPN for a couple of servers.
In brief, the current problem, which I believe is the one problem preventing from using pfSense is that the clients (one Windows and one Linux) cannot ping to the pfSense LAN interface. Interestingly, I can connect to the Linux box via SSH and HTTPS (Web GUI) from the Internet. I can also Ping from within pfSense LAN interface to each box, as well as, from pfSense LAN to pfSense WAN and pfSense LAN to the Internet. However, no ping is possible from the Linux box to the Windows box. Also, since this is AWS and of this problem, I cannot log into the Windows box.Thus the situation appears that the clients cannot reach out to pfSense or each other; but can receive.
What I have done:
- Starting over (many times), and following the guidelines as given at the Netgate VPC User Guide:
http://www.netgate.com/docs/aws-vpn-appliance/vpc-guide.html - I have have made a couple of modifications from the guide in order to have things run, as described here (the doc appears to be out of date):
– In the step of providing the Interface information for the Public WAN, I provided an IP, rather than having AWS provide one.
-- The User Guide skips of what to do with the WAN setup. Going with Dynamic for the WAN would not allow for the pfSense LAN to ping to the WAN interface or the Internet. Thus went with a Static IPv4 for the WAN. - There is a bug with getting the LAN interface installed, due to DHCP IPv6 running on the Interface. Following this Bug Report fixes the issue to create a IPv4 LAN interface:
https://redmine.pfsense.org/issues/6458
Of Note:
- On the pfSense LAN interface in AWS, I have disabled the Source/Desk Check (as stated in the user guide).
- The Firewall NAT for Outbound is set to: Manual Outbound NAT rule generation (as stated in the guide). I have tried Auto, but does not work as well.
- Have added the Private LAN IP address into the Network_to_NAT Alias
- No additional Gateway is added into the pfSense LAN interface (the Gateway field is left blank). Only one Gateway is used, which is for the WAN (listed in the System -> Routes section)
- Due to the AWS infrastructure, the xxx.xxx.xxx.1 (LAN Side) is reserved and thus not set to a gateway. The Linux NIC has the Gateway set to the pfSense's LAN IP (ex: 192.168.1.5)
- Firewall permissions in the AWS section have been set to allow everything from the Internet 0.0.0.0/24 to the Ports required for PfSense and of the internal servers. I know of the security risks, but just for the install to get things going.
- I have not set the VPN up at this time.
Lastly:
- Also, with the standard install, Errors for the Default Install occur due to the Default LAN Firewall Rules (LAN INET). If deleting the LAN Interface and recreate one, the Default LAN rule is deleted as well. If recreating one, or changing the LAN INET rule to allow for Protocol of "any", no errors are reported.
- For Firewall Logs, only WAN events are being reported, I see no events of LAN events being tracked, either blocked or passed.
- For DHCP and DNS, when enabled, neither client reports in for a lease. I have to enter their information for static IPs and entries.
Simple Network Diagram (just using the Linux box for now)
|Linux| –- [pfSense] –- InternetSoooo....
From just installing onto AWS, is there something missing or reconfigured of why a client will not ping/connect to pfSense (LAN side); but pfSense can ping to the Client?Thanks for any help/suggestions.
I can also provide the full listing of steps I have used (per click basis you could say)*** EDIT ***
Have also updated pfSense AWS to the latest update.
And of the LAN Rules in use:
(The INET rule is what has caused some kind of errors) - Starting over (many times), and following the guidelines as given at the Netgate VPC User Guide:
-
An Update:
Well, have not been able to get the Linux box operable; however, I have managed to get the Windows box capable with RDP.
However, can only RDP into it and that is about it.The Windows box confirms the situation with the Linux client in that, the clients cannot ping back to the pfSense LAN/WAN, nor go into the Internet.
They can receive, but not send.Something in which the documents for the pfSense Docs forget to mention is how to connect clients to the AWS network.
- Appears that in order to launch a new instance into the network, that client must first be configured with two NIC's, one for the WAN and one for the LAN.
- Before starting the new client; pfSense must be turned off, and the Elastic IP switched over to the new client's WAN.
- Turn on the new client and then connect to it.
- Change the second NIC to a static IP address for the pfSense LAN side, make a note of the Hostname as well; and then turn off. (DHCP for pfSense appears to not work within AWS.)
- Reconfigure the Elastic IP back to pfSense.
- Power up pfSense and then the new client.
- In pfSense's DHCP and DNS services; manually add in the configuration details (MAC, IP and Hostname)
- Make the Port Forwarding rules as required, such as 3389 for Windows RDP.
(Which by the way, can access and log into pfSense from the client)
But yet, cannot ping to pfSense's LAN/WAN interfaces or access the Internet from the clients.
-
I have the same problem :(
-
Thanks to the reply… Humm, well I have not packages installed, but if that was the case, it would seem to be a deal breaker, considering that has been a year of being open.
On another note....
I thought the problem would be with AWS Security Groups. But after exhausting that route, the problem still remains. I have even set the computers into the same security group, of which is open to everything and the world... and yes, those rogue scans just started right up.So, the problem looks to be within pfSense of letting LAN clients access outwards, or maybe as a VPN to remote to them; but not allowing them to be able to update and such seems to be useless.
I assume that is not intentional, likely a bug I guess.
Though I would be happy if it is something of being misconfigured. -
Latest update…
Believe I have figured it out, but running some last checks to optimize/cleanup.
The problem is that the Routing Tables in AWS need to be corrected, which was not part of the documentation.
Briefly, as it stands with v2.3.2, there are Three Problems (but all fixable) when Installing the pfSense AMI on AWS:
1. A LAN Interface cannot be added until the Bug Fix of Disabling DHCP6 via SSH is performed. (See First Post)
2. The LAN INET Firewall Rule is broken, and needs to be fixed by either editing it, for Protocol "any" or deleted and a new LAN Default Rule is created.
3. The Route Table for the Private LAN needs, just a little... just a little explanation of how to get clients to work with pfSense. The following steps should be part of the Install Documentation:Fixing the Routing Tables
- In AWS: Go to Services -> VPC -> Route Tables
- Select the Route which is for the Private LAN. This will be the one, which has 0 Subnets and Yes for Main
- Click on the Routes Tab
- Click on the Edit Button
- Click on the Add Another Route button
- For the Destination, enter 0.0.0.0/0
- For the Target, click in the field and see if the pfSense instance populates.
--- If so, click on it. If not, find the Instance ID of the Instance (EC2 Console -> Instances) and copy it.
--- Paste the Instance ID into the Target. It should then populate. If not, may need to wait some time for AWS infrastructure to propagate with the newly created instance. - Click on Save
- If there is an Error, in regards of multiple interfaces, then copy the Network Interface ID of the LAN (EC2 Console -> Network Interfaces), which begins with "eni". Insert the LAN's Network Interface ID into the Target Field. It should then populate. Click on Save
- Click on the Subnet Associations Tab
- Click on the Edit Button
- Check the box for the Private LAN subnet
- Click on Save
AWS Security Groups, may be another item, in which different Security Groups need access to one another.
That is to have the Inbound Rules set to All Traffic with the Source of the communicating Security Group. I have not verified this as of yet. But as of now, I can have a Windows Client pull Updates and browse to Google… but not Bing... which is weird.... not that it really matters..... but is odd......Will publish the steps I took in a separate thread, once I clean things up.