Odd problem; I had the following set up:
[[machine with paramiko 10.100.x.x]] –|
| —–(int X) 10.100.x.x [[pfsense]] (int Y) 10.2.x.x —– | —— [[10.2.x.x machine B]]
[[machine A 10.100.x.x]] ——————|
I had a script on the paramiko machine connecting via ssh and sftp to machines A and B. Connections to machine B had no problem whatsoever. Connections to machine A, however, would work 5% of the time, and drop the rest of the time either when setting up the channel to execute a command over ssh, or when invoking the sftp subsystem on the remote machine. Normal ssh and sftp connections (not using paramiko) had no problems whatsoever. Also, when pfSense filtering was turned off, there were also no problems.
It turned out that pfsense was dropping a lot of packets sent by paramiko due to fragmentation (logs show TCP:PA, TCP:RA and TCP:A). Unfortunately, tweaking pfsense settings didn’t help here (some people have reported that setting Firewall Optimization Options (under Advanced > Firewall/NAT) to conservative worked – that didn’t help me unfortunately – or disabling firewall scrub worked – which I couldn’t do as it’s required by NAT).
I haven’t been able to figure out exactly what the problem is. The packets received by machine B and machine A (with filtering off) look exactly the same. I’m tempted to think this is a pfsense problem, although I have no specific proof (I’ve tested with multiple machines in position of machine A by the way, compared ssh settings, ensured there were no other connectivity problems in the way).
In the end, I’ve set up another network (virtual one, since these are VMs – 10.100.x.x machines plus pfsense on one physical host, and 10.2.x.x on another) connecting these VMs directly to eachother, to bypass pfsense for these connections.
I’m sure this will apply to other models as well. Trying to make configuration changes to the interface gives an error similar to: “cannot edit interface, interface currently in use”. Sadly, simply unplugging the interface is not the solution. In my case, I had to remove the interface (or rather, an address that routes through that interface) as a DNS Proxy to allow it to be editable (other things I also tried that may or may not be required: deleting all policies associated with the zone the interface is in – I’ve tested this and it looks like it’s not required; deleting policy elements -> addresses for that interface; deleting an address using the interface from DNS -> Host).
I basically went through my config file looking for things referencing the zone that the interface was in / interface / IP addresses that route through that interface. Unfortunately it’s quite irritating.
I used this guide to set up the VPN between my Juniper SSG5 and Shrew Soft client, however, it has a disadvantage; the VPN can only be tunnelled into one zone. To fix this, you can change the VPN from policy-based to route-based.
- Backup your config…
- Delete the VPN policies
- Create a new zone for your VPN – I called mine “VPN”
- Create a new tunnel interface in the new zone, make it unnumbered, and set the interface to whatever interface the incoming VPN will be going through (probably WAN)
- Go into VPNs > AutoKey IKE > edit > advanced, and select to bind to your tunnel interface
- Network > Routing > Destination, create a new route from the IP pool to the tunnel interface
- Create policies allowing communication between your VPN zone and whatever zones it should communicate with
- Test! (No changes needed on Shrew Soft)
I did read a forum post about adding multiple policies, but my SSG5 gave errors that the IKE was already part of another policy when I tried to set up the additional policies. This method seems to work though.
In this case, I’m NATing 10.8.0.0/16 (interface name = vlan8) to 10.120.0.0/16 (interface name = int8), so a packet to 10.8.150.3 will be NATed to 10.120.150.3.
Go to Firewall -> Nat
Create a new 1:1 mapping, and put the settings as follows:
External subnet IP: 10.8.0.0
Internal IP: int8 subnet
Destination: any (you might be able to use int8 subnet here, but it wouldn’t work with my VPN configuration as VPN IPs are on a separate subnet)
NAT reflection: use system default
And save, now to Firewall -> virtual IPs
Create a new virtual IP
I’ve used CARP, but when I get the chance I’ll try Proxy ARP, which would be better for those who have an entire subnet behind the pfsense (I don’t, so I need to put in each address to NAT individually)
And then the settings on your host behind the pfsense:
IP: 10.120.150.3/16 (whatever IP you want)
gw: 10.120.x.x (IP of pfsense’s int8 interface)
(to set the gateway in Ubuntu, using /etc/network/interfaces didn’t seem to want to work for me, so I used “route add default gw 10.120.x.x” instead)
This issue may well effect other firewall models, but I’ve just been playing with the SSG 5.
I want to
Be able to reach 10.9.x.x and 10.10.x.x using my VPN connect (it’s set up like this, by the way)
– With one VPN connection, two policies on the Juniper and in Shrew Soft; for some reason, the wrong policy is often used and my packet gets dropped due to not having a policy to allow it
– With one VPN connection, one policy on Juniper and Shrew (CIDR covering both addresses); also not working, the policy isn’t matching at all, weirdly
– With one VPN connection, two policies in Shrew and one policy using a IP address group in Juniper; policy not matching again…
– With two VPN connections, two policies in Shrew and Juniper; still not working!! policies not matching if both VPNs are active as Juniper seems to disregard which VPN the packet has come from
– With one VPN connection, two policies in Shrew and one ANY policy on Juniper; also not working…think Juniper just doesn’t like this policy
Pick the last problem above; use one VPN connection, whatever policies you need in Shrew and one ANY policy in Juniper, then, log onto your SSG, and use the following command:
unset ike policy-checking
That was much more difficult than it should have been…
Similar to the previous post…this was the method I tried first to block some spammy IP addresses connecting to Apache (they were not spammy enough for me to worry about the resource-usage difference between hosts.deny and iptables – it is better using ufw/iptables), and it didn’t work.
I found an awesome forum post describing why that I’d like to save for future reference.
Files hosts.allow and hosts.deny work through a daemon (a program running in the background) called inetd. (On some systems, xinetd is used.) Other files used by inetd are /etc/services and /etc/inetd.conf. The purpose of inetd is to listen on various ports; when it accepts a connection on one of these ports, it fires up the appropriate service.
You can set up your system so that one of the services that inetd passes off connections to is a web server. For the purpose of efficiency, though, most systems do not have their web servers set up that way; they listen directly to the appropriate ports (usually port 80 at least).
If your web server is configured so that it listens directly to the appropriate ports, then inetd is not offering the protection you request in file hosts.deny. There’s nothing wrong with this; you just have to configure your web server (Apache, in your case?) to provide the appropriate protection.
Check the order…I stupidly assumed it would match the last rule as that’s the most recent rule you’ve added…but nope! It matches the first rule, so if you add a rule to allow incoming connections on port 80, then try and block an IP address that’s spamming you with bad requests, it won’t work unless you add an extra parameter (that I’d not heard of before, and I’ve read a few posts on setting up / using UFW – it’s right at the end of the list of parameters on the UFW online man page though) to push the new rule above others.
It also doesn’t add a rule if you have the same existing rule, even if you’re trying to add it above the existing rule (ie, give it a higher priority).
So, list the existing rules with numbers:
ufw status numbered
Delete any rules you want to move up (eg, rule number 8):
ufw delete 8
Add a rule in a particular place (eg, at the very top of the rules):
ufw insert 1 deny from bad.spammy.ip.address