@gertjan

I don't see any traffic from the Amazon Echo when using Wireshark (this is very strange) with one caveat. It was in a failure mode. I fired up Wireshark to start debugging. I first filtered on the source IP address (ip.src == 192.168.1.162). I saw some records from the Amazon Echo that it is using MDNS protocol. A web search led me to these resources:

https://docs.netgate.com/pfsense/en/latest/packages/avahi-package.html
https://www.lawrencesystems.com/pfsense-and-rules-for-iot-devices-with-mdns/

Avahi is a system which facilitates service discovery on a local network. This means that a laptop or computer may be connected into a network and instantly be able to view other people to chat with, find printers to print to or find files being shared.

I installed Avahi and placed the Echo back in the VPN tunnel. Later on in the day, it stopped working again about 12 hours later. The Echo only appears to work consistently when assigned to the WAN iface. This morning, I assigned the Amazon Echo back to the VPN iface and will monitor some more. Based on my last experiment, I expect it to fail sometime within the next 12 hours.

@kom said in pfSense not responding to any ports:

I don't have the time to dig deep into this and I'm not really an IPSec guy, but my first random guess would be asynchronous routing.

yeah I've had some trouble with packets going back and forth via different routes due to the complex routing config here... which is why I had to mess with some of the sloppy state firewall rules. However, those were all caught by the firewall and logged. The puzzler here is nothing is showing in the firewall logs this time.. so I don't even know where to start to try and fix it.

The part I can't figure out is why there is no response caught by tcpdump. Even if the packet is lost in routing, shouldn't there still be an outbound packet? Also.. one-way connections work both ways which is also odd. Argh.. what a headscratcher.

That is likely either a filesystem issue or an issue with the disk itself.

First thing to do is boot it into single user mode and run fsck -y / a few times until it doesn't find any problems or fix any problems.

If that is all clean and the problem persists, try running a SMART test on the disk to see if anything turns up.

There are not currently any plans to take on mirrors from third parties.

Hello Steve
The Pfsense does not have DHCP server
There are many PC navigate on the same subnet. All with static IP (10.1.1.x)
So, I have one PC to be LTSP server inside the same subnet.
The dnsmasq do it a DHCP server for LTSP clients. In this way that I have no ability to fix the communication through Ltsp server/client/PFsense to out internet or have ping answer.

Thank you

Douglas

@stephenw10 said in LTSP - Pfsense - (clients LTSP UP but not connect Internet):

You should be able to ping 8.8.8.8 without DNS.

Check the routing table on the client run netstat -rn.

The only other explanation is that the rules you have in pfSense are somehow passing only traffic from the server and not the clients. But the default allow rules on LAN would apply to all traffic from that subnet.

Steve

Thanks for the insight Steve, this information you provided me saved me lots of time. Appreciate it, the previous guy had put a SYSlog server into place, but the license had expired so I lost out on that end as well lol. Still no word from the data center.

Chris

This is a 2 year old thread, with no details when first asked.

I would suggest you start your own thread with details of "exactly" what your doing... Large number of certs means what 10, 100, 20,000? For example of a bad way to ask a question.

https://www.netgate.com/products/tnsr/

@stephenw10 Good to know! That has already been taken care of in this instance by accident, but it's good to know for the future! Much appreciated :)

@jknott
The PFsense kernel is compiled with option "device ENC", so you can see this interface even if you don't use IPSEC. In this case, it is in the state "down".

Is the ERL also routing and NAT'ing?

If the AT&T routing has a 192.168.2.X sibnet on it's LAN then it is not in bridge/modem mode. The subnet between the AT&T LAN and the ERL WAN and everything on it, including pfSense, will be 192.168.2.X.

So probably you need to set the bridge interface to the .2.X subnet. Then you will be able to add the AT&T router as a gateway.

A diagram might help a lot here.

Steve

@coreybrett said in TINC:

Unfortunately I can't find any documentation for the package. I've played with it a bit, but haven't had much luck.

Yes, THAT is the "problem"

and there are a few "quirks" that is not "true" to the way tinc actually operates, like the forcing of an address in the host configuration, even though it's a host that is not going to be connected to and would be a dynamic IP host.

Okay... Corrected itself. (smacks forehead...)

Because netgate/pfsense no longer provide unsupported version for download for security reasons
https://forum.netgate.com/post/788629

There would be zero reasons to run those OLD unsupported versions that do not have current security issues corrected, etc.

Thanks for the help, Steve.

I can't get this working properly. Tried with this NAT rule:
0_1550324449733_Capture.PNG

The secondary gateway (IP 10.10.10.1) doesn't seem to be able to communicate through the GIF tunnel.

Also tried with the option discussed above (with patches), no more luck. No byte is going through the tunnel.

0_1550324584001_Capture2.PNG

Any idea of what's going on ?

If you want to use Netflows to view that then you need a netflow collector to export the data to.

If you only need an instantaneous reading you could use something like wireshark that can graph traffic from a packet capture.

https://docs.netgate.com/pfsense/en/latest/monitoring/monitoring-bandwidth-usage.html

Steve