Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
knitti wrote: On 10/19/07, Stephen Bosch [EMAIL PROTECTED] wrote: Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: We don't support JetDirect over WAN connections. look with tcpdump, whether the packets of the printserver look like you expect. perhaps it only has a ttl of 1 or 2 ;-) No -- the damn thing is doing ARP for the remote address, even though it has a gateway configured. The stupid thing is that this same model of printer works on another network, same configuration -- except the local VPN endpoint is a SonicWall. -Stephen-
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
On Fri, 2007-10-19 at 00:30 -0600, Stephen Bosch wrote: Hi, folks: Here's a good one for you. I have an IPsec tunnel running between two OpenBSD boxes. One is still running 3.8 (yes, it needs to be updated) and the other is running 4.1. There is a functioning tunnel running between the two devices. Hosts on one end can see hosts on the other, and vice versa -- EXCEPT we just put an HP Jetdirect print server on the OpenBSD 4.1 side. This device is pingable and accessible from hosts on the same network, but totally unpingable and inaccessible from hosts on the remote network. To recap: Print server is at site A. Hosts at site A (on the same subnet) can ping and access print server. Hosts at site B (on a different subnet) *cannot* ping or access this print server. And yet - Hosts at site B *can* see every other device at site A (and vice versa) and all those devices can see the print server. Note that we're not doing any filtering on the encryption interface (the line is pass quick on enc0); nevertheless, I'm wondering if I need some special flags somewhere. Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: We don't support JetDirect over WAN connections. We ended up putting the printer outside on a public IP address as an ugly, undesirable workaround, and, WAN connection or not, that is currently working. I'd really like to get this one back on the private network. I don't need hackers sending mountains of porn to this printer, even if it *is* in a truck stop. Any ideas or salient suggestions? -Stephen- hi Stephen, No offense, but did you check JetDirect's ip settings about the default gateway ? Try an tcpdump on the ethernet interface at site A while trying to print from site B and check if you see packets on both directions. -- Claudiu Pruna [EMAIL PROTECTED]
A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
Hi, folks: Here's a good one for you. I have an IPsec tunnel running between two OpenBSD boxes. One is still running 3.8 (yes, it needs to be updated) and the other is running 4.1. There is a functioning tunnel running between the two devices. Hosts on one end can see hosts on the other, and vice versa -- EXCEPT we just put an HP Jetdirect print server on the OpenBSD 4.1 side. This device is pingable and accessible from hosts on the same network, but totally unpingable and inaccessible from hosts on the remote network. To recap: Print server is at site A. Hosts at site A (on the same subnet) can ping and access print server. Hosts at site B (on a different subnet) *cannot* ping or access this print server. And yet - Hosts at site B *can* see every other device at site A (and vice versa) and all those devices can see the print server. Note that we're not doing any filtering on the encryption interface (the line is pass quick on enc0); nevertheless, I'm wondering if I need some special flags somewhere. Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: We don't support JetDirect over WAN connections. We ended up putting the printer outside on a public IP address as an ugly, undesirable workaround, and, WAN connection or not, that is currently working. I'd really like to get this one back on the private network. I don't need hackers sending mountains of porn to this printer, even if it *is* in a truck stop. Any ideas or salient suggestions? -Stephen-
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
knitti wrote: On 10/19/07, Stephen Bosch [EMAIL PROTECTED] wrote: Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: We don't support JetDirect over WAN connections. look with tcpdump, whether the packets of the printserver look like you expect. perhaps it only has a ttl of 1 or 2 ;-) Yeah, I'm going to do some packet sniffing with tcpdump :) The TTL is unlikely to be the cause as the printer works now that it is on the outside, and the remote site is 8 hops away... but the suggestions about MTU possibly causing trouble are worth investigating. Anyway, I'll try tcpdump and see what it turns up. Thanks for all the suggestions and help! Cheers, -Stephen-
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
Jussi Peltola wrote: Does the print server have the right gateway configured? Yeah. Checked that. Does scrub have any effect (fragments get dropped in some cases if scrub is off - that bit me once with openvpn)? I think scrub is on, though -- I'll have to look again. Wouldn't tcpdump tell you more about the packets coming back from it? Yes, it would, but I'd been working for 20 hours and I couldn't really think anymore. Plus, doing a dump on an encryption interface... well. I'd probably just use rdr and a TCP proxy on some machine to work around the problem. Print server IP stacks tend to be funny, especially in case of non-1500 MTU. That was my thinking also -- I don't think they spend a lot of time on them, and they run on bare minimum hardware. Thanks! -Stephen-
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
Does the print server have the right gateway configured? Does scrub have any effect (fragments get dropped in some cases if scrub is off - that bit me once with openvpn)? Wouldn't tcpdump tell you more about the packets coming back from it? I'd probably just use rdr and a TCP proxy on some machine to work around the problem. Print server IP stacks tend to be funny, especially in case of non-1500 MTU. -- Jussi Peltola
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
On 10/19/07, Stephen Bosch [EMAIL PROTECTED] wrote: Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: We don't support JetDirect over WAN connections. look with tcpdump, whether the packets of the printserver look like you expect. perhaps it only has a ttl of 1 or 2 ;-) --knitti
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
Claudiu Pruna wrote: hi Stephen, No offense, but did you check JetDirect's ip settings about the default gateway ? None taken. Yes, I did actually check that, and it was correct. Try an tcpdump on the ethernet interface at site A while trying to print from site B and check if you see packets on both directions. That'll be the next thing I try. -Stephen-
