THE SETUP:
A pfSense 1.2.2 box, the 'firewall', is providing a gateway to the
Internet and DNS forwarder. LAN is 192.168.254.0/24.
An additional pfSense 1.2.0 box, the 'printer router', is on the LAN,
routing to a shared network on its WAN interface (192.168.1.0/24) for
access to a shared Canon iRC3080i printer (on 192.168.1.101).
The firewall has a static route pointing to the network with the shared
printer via the printer router.
The firewall's LAN interface is xl0.
THE ISSUE:
Printing was working fine when IPCop did the job of the firewall along
with the pfSense 1.2.0 printer router. When I migrated the firewall to
pfSense 1.2.2 printing stopped working properly.
Here is a description of the issue from my colleague who's been dealing
with this before me:
The printer receives the job but fails with a NG#857 error, which
according to the manual means a network
issue (Data reception timed out, or the job was cancelled at the host).
The job stalls after about page 2 or about 70k ... nothing over about
50-100k will print (so just text or test page - which kind of makes a
mockery of test pages but there you go...). Printing when connected direct
to the printer works fine.
The only thing in the firewall logs is this...
rule 60/0 (match) : block in on xlt :
192.168.254.238.1306192.168.1.101.9100:tcp 20 [bad hdr length 0 - too
short, 20]
The rule that triggered this action is: @60 block drop in log quick all
label Default deny rule
This error is coming up for lots of other addresses on the internet as
well (and that is working fine) so can't be sure that this is the problem,
but it's all the log is giving me. Some data is always sent
I had previously assumed the firewall woulnd't be involved with this
printing traffic, instead directing workstations (via DNS) to send their
printing traffic straight to the printer router on the LAN. But I think
this is a misunderstanding on my part.
As I understand it all LAN traffic isn't firewalled by default, so why is
the firewall blocking this?
Is xlt an interface name? I don;t see any interfaces with this designation.
Seeing as printing worked fine when going via IPCop and then through
pfSense 1.2.0 to the printer, then fail when going via pfSense 1.2.2 and
then through pfSense 1.2.0 to the printer, could the problem be a change
between pfSense 1.2.0 (on FreeBSD 6.2) and pfSense 1.2.2 (on FreeBSD 7.0)?
There's a comment on how FreeBSD 7's 'pf' differs from FreeBSD 6's pf,
causing the same error message as above, here:
http://www.nabble.com/default-snaplen-on-tcpdump-td15712249.html
Brad Gillette has a similar sounding issue as this which he reported to
this list today.
Any help would be very much appreciated, thanks.
--
Pete Boyd
Open Plan IT - http://openplanit.co.uk
The Golden Ear - http://thegoldenear.org
-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
