SFTP Access

stephenw10

Since disconnecting one WAN didn't have an effect it seems unlikely to be a load-balancing problem. Even so you might want to enable 'sticky connections' or exclude that site from the load balancing.

Check the firewall logs after you've tried to connect.

Steve

johnpoz

is it a simple name resolution problem? Connection timed out could be lots of things. Sniff on pfsense lan and validate its resolving and sending connection request to the correct IP, etc. As stated I can connect and get a banner of sorts back.

Unless your blocking on pfsense outbound traffic pfsense doesn't care where you go. And could not distinguish this ip from the next IP What are you current lan rules and or floating rules, are you using aliases in allowing traffic?

ehanover

Stephenw10, where would I exclude that site from the load balancing?

johnpoz: Not a name resolution problem, I've done a nslookup and it resolves fine. Will look at the sniffing on the lan to see if I can tell more of what is happening.

Rui

ehanover

I have attached the only floating rule I have in a jpg.

Here is the packet capture from pfsense on the LAN port:

10:41:57.666222 00:22:19:07:47:28 > 00:13:72:0f:57:92, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 13837, offset 0, flags , proto TCP (6), length 52)
    192.168.1.23.64669 > 66.179.147.73.22: Flags , cksum 0x9241 (correct), seq 1772273340, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:42:00.666022 00:22:19:07:47:28 > 00:13:72:0f:57:92, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 13840, offset 0, flags , proto TCP (6), length 52)
    192.168.1.23.64669 > 66.179.147.73.22: Flags , cksum 0x9241 (correct), seq 1772273340, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:42:06.666431 00:22:19:07:47:28 > 00:13:72:0f:57:92, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 128, id 13844, offset 0, flags , proto TCP (6), length 48)
    192.168.1.23.64669 > 66.179.147.73.22: Flags , cksum 0xa650 (correct), seq 1772273340, win 8192, options [mss 1460,nop,nop,sackOK], length 0

Not sure exactly what I'm looking at.

floating.jpg_thumb

johnpoz

Well I think the way you posted it caused the lines in the text..

But here
192.168.1.23.64669 > 66.179.147.73.22

that is that IP talking to that fqdn you posted sftp.link2gov.com [66.179.147.73] on port 22 or ssh/sftp port.

And here is answer back

192.168.1.23.64669 > 66.179.147.73.22

So clearly pfsense is not blocking the traffic.. Load it up into wireshark and see if your seeing RST come back or something. So I would assume syn, and then syn,ack - but then there is another answer back.. maybe RST?? what does wireshark show?

cmb

There isn't anything in reply in that capture snippet, only LAN outbound.

Go to Diagnostics>States and filter on that 66.179 IP, what do the states look like?

ehanover

Here is the States Filter results:

tcp 66.179.147.73:22 <- 192.168.1.23:49769 CLOSED:SYN_SENT
tcp 192.168.1.23:49769 -> 100.1.217.93:21780 -> 66.179.147.73:22 SYN_SENT:CLOSED

ehanover

I tried 'sticky connections' and excluded that site from the load balancing without any effect.

Rui

kejianshi

Is your SFTP server a machine on the LAN? (maybe a dumb question)

Is that all that machine does is SFTP?

which version of pfsense are you using?

johnpoz

My bad - you are correct there was no answer back, the lines thru the text must of confused me ;) hehehe

So I would suggest now sniff on the wan - do you not see an answer?

ehanover

So here it is guys. It seems that this particular site does not like a dual WAN firewall. I setup another pfsense box without the dual WAN and I can now access the site right through the firewall.

That's too bad I was really linking the extra bandwith. I will now try to setup CARP so that I can at least have redundancy.

Thanks for all the suggestions and help.

Rui

cmb

It's almost certainly not the fact it's dual WAN, that site isn't replying to/is blocking the source IP you're sending it out from, or maybe a general connectivity issue for that network. A traceroute might be telling. The states you showed prove it's getting sent out no problem, getting NATed as it appears it should be, but gets no reply back at all.