Re: Weird routing problem on simple CARP setup
That makes sense. Thanks for your advices. -- Cordialement, Pierre BARDOU -Message d'origine- De : Stuart Henderson Envoyé : mercredi 11 juillet 2018 23:24 À : misc@openbsd.org Objet : Re: Weird routing problem on simple CARP setup On 2018-07-11, Tom Smyth wrote: > Hi Pierre, > > with VRRP on other vendors the IP on the Virtual interface is > recommended to be a /32, > > > afaik > it prevents ambiguity when it comes to your connected routes do you > route a packet out the carp interface which as an ip on the configured > /24 network or do you route the packet out the physcial interface > which also has a /24 network configured > > > I note the examples and faq page in openbsd show ips configured with > a /24 configured https://man.openbsd.org/carp > > and a /24 seems to be the default ip if a subnet mask is not specified > > > But I would love to hear / learn more experienced OpenBSD Admins Devs > take on it My GBP0.02 (which isn't worth much these days ;) - generally /32 for addresses on carp - if there are no IPs from the subnet used in carp on another "real" interface (i.e. the address is only on the carp interface) then use the full /XX for one IP in that subnet on carp - if you're redistributing a subnet on a carp interface into OSPF you need the full /XX on the carp interface so it can announce the network rather than a single host (you want to announce it from carp rather than the "real" interface so the priority changes depending on the carp state)
Re: Weird routing problem on simple CARP setup
On 2018-07-11, Tom Smyth wrote: > Hi Pierre, > > with VRRP on other vendors the IP on the Virtual interface > is recommended to be a /32, > > > afaik > it prevents ambiguity when it comes to your connected routes > do you route a packet out the carp interface which as an ip on the configured > /24 network or do you route the packet out the physcial interface which also > has a /24 network configured > > > I note the examples and faq page in openbsd show ips configured > with a /24 configured > https://man.openbsd.org/carp > > and a /24 seems to be the default ip if a subnet mask is not specified > > > But I would love to hear / learn more experienced OpenBSD Admins > Devs take on it My GBP0.02 (which isn't worth much these days ;) - generally /32 for addresses on carp - if there are no IPs from the subnet used in carp on another "real" interface (i.e. the address is only on the carp interface) then use the full /XX for one IP in that subnet on carp - if you're redistributing a subnet on a carp interface into OSPF you need the full /XX on the carp interface so it can announce the network rather than a single host (you want to announce it from carp rather than the "real" interface so the priority changes depending on the carp state)
Re: Weird routing problem on simple CARP setup
Hi Pierre, with VRRP on other vendors the IP on the Virtual interface is recommended to be a /32, afaik it prevents ambiguity when it comes to your connected routes do you route a packet out the carp interface which as an ip on the configured /24 network or do you route the packet out the physcial interface which also has a /24 network configured I note the examples and faq page in openbsd show ips configured with a /24 configured https://man.openbsd.org/carp and a /24 seems to be the default ip if a subnet mask is not specified But I would love to hear / learn more experienced OpenBSD Admins Devs take on it Thanks Tom Smyth On 11 July 2018 at 16:47, BARDOU Pierre wrote: > Hellom > > Sorry for the long delay, I've been very busy recently. > > Putting the carp in /32 works. > What's the best practice when you have a physical IP + CARP in the same > subnet ? > The FAQ here https://www.openbsd.org/faq/pf/carp.html#failover uses the same > netmask for the CARP and the physical interface. > > I upgraded to 6.3 and it also works. > > Thank you for your help > > -- > Cordialement, > Pierre BARDOU > > -Message d'origine- > De : Stefan Sperling > Envoyé : mardi 3 juillet 2018 13:33 > À : BARDOU Pierre > Cc : misc@openbsd.org > Objet : Re: Weird routing problem on simple CARP setup > > On Wed, Jun 27, 2018 at 09:30:16AM +, BARDOU Pierre wrote: >> Hello, >> >> I have a strange problem with OpenBSD 6.2, which looks like a bug. >> Steps to reproduce : >> >> * sh /etc/netstart -> everything works. Routing table : >> root@fw-t-wan-chut01:~ # netstat -rnf inet >> Routing tables >> >> Internet: >> DestinationGatewayFlags Refs Use Mtu Prio Iface >> default10.194.119.254 UGS0 16 - 8 bge0 >> 224/4 127.0.0.1 URS0 798 32768 8 lo0 >> 10.194.116/22 10.194.116.29 UCn11 - 4 bge0 >> 10.194.116/22 10.194.116.28 UCn00 -19 carp0 >> 10.194.116.28 00:00:5e:00:01:0f UHLl 03 - 1 carp0 >> 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 28 - 1 bge0 >> 10.194.119.254 00:1b:2a:e9:c4:00 UHLch 25 - 3 bge0 >> 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 >> 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 >> 127/8 127.0.0.1 UGRS 00 32768 8 lo0 >> 127.0.0.1 127.0.0.1 UHhl 1 1122 32768 1 lo0 >> 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 >> 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 >> 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 >> root@fw-t-wan-chut01:~ # ifconfig carp0 >> carp0: flags=8843 mtu 1500 >> lladdr 00:00:5e:00:01:0f >> description: TL-INT-ADM-WAN >> index 10 priority 15 llprio 3 >> carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 >> groups: carp >> status: master >> inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 >> >> * then sh /etc/netstart carp0 -> routed traffic stops working (ping >> 10.194.125.120 says "sendmsg: Invalid argument"). >> Same result if I do ifconfig carp0 10.194.116.28/22. > > Have you tried using a /32 mask on carp0 instead of /22? > That might work around the problem. > > I believe this problem is fixed in 6.3. Can you confirm? > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Weird routing problem on simple CARP setup
Hellom Sorry for the long delay, I've been very busy recently. Putting the carp in /32 works. What's the best practice when you have a physical IP + CARP in the same subnet ? The FAQ here https://www.openbsd.org/faq/pf/carp.html#failover uses the same netmask for the CARP and the physical interface. I upgraded to 6.3 and it also works. Thank you for your help -- Cordialement, Pierre BARDOU -Message d'origine- De : Stefan Sperling Envoyé : mardi 3 juillet 2018 13:33 À : BARDOU Pierre Cc : misc@openbsd.org Objet : Re: Weird routing problem on simple CARP setup On Wed, Jun 27, 2018 at 09:30:16AM +, BARDOU Pierre wrote: > Hello, > > I have a strange problem with OpenBSD 6.2, which looks like a bug. > Steps to reproduce : > > * sh /etc/netstart -> everything works. Routing table : > root@fw-t-wan-chut01:~ # netstat -rnf inet > > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default10.194.119.254 UGS0 16 - 8 bge0 > 224/4 127.0.0.1 URS0 798 32768 8 lo0 > 10.194.116/22 10.194.116.29 UCn11 - 4 bge0 > 10.194.116/22 10.194.116.28 UCn00 -19 carp0 > 10.194.116.28 00:00:5e:00:01:0f UHLl 03 - 1 carp0 > 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 28 - 1 bge0 > 10.194.119.254 00:1b:2a:e9:c4:00 UHLch 25 - 3 bge0 > 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 > 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 1 1122 32768 1 lo0 > 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 > 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 > 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 > root@fw-t-wan-chut01:~ # ifconfig carp0 > > > carp0: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0f > description: TL-INT-ADM-WAN > index 10 priority 15 llprio 3 > carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 > groups: carp > status: master > inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 > > * then sh /etc/netstart carp0 -> routed traffic stops working (ping > 10.194.125.120 says "sendmsg: Invalid argument"). > Same result if I do ifconfig carp0 10.194.116.28/22. Have you tried using a /32 mask on carp0 instead of /22? That might work around the problem. I believe this problem is fixed in 6.3. Can you confirm?
Re: Weird routing problem on simple CARP setup
On Wed, Jun 27, 2018 at 09:30:16AM +, BARDOU Pierre wrote: > Hello, > > I have a strange problem with OpenBSD 6.2, which looks like a bug. > Steps to reproduce : > > * sh /etc/netstart -> everything works. Routing table : > root@fw-t-wan-chut01:~ # netstat -rnf inet > > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default10.194.119.254 UGS0 16 - 8 bge0 > 224/4 127.0.0.1 URS0 798 32768 8 lo0 > 10.194.116/22 10.194.116.29 UCn11 - 4 bge0 > 10.194.116/22 10.194.116.28 UCn00 -19 carp0 > 10.194.116.28 00:00:5e:00:01:0f UHLl 03 - 1 carp0 > 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 28 - 1 bge0 > 10.194.119.254 00:1b:2a:e9:c4:00 UHLch 25 - 3 bge0 > 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 > 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 1 1122 32768 1 lo0 > 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 > 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 > 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 > root@fw-t-wan-chut01:~ # ifconfig carp0 > > > carp0: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0f > description: TL-INT-ADM-WAN > index 10 priority 15 llprio 3 > carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 > groups: carp > status: master > inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 > > * then sh /etc/netstart carp0 -> routed traffic stops working (ping > 10.194.125.120 says "sendmsg: Invalid argument"). > Same result if I do ifconfig carp0 10.194.116.28/22. Have you tried using a /32 mask on carp0 instead of /22? That might work around the problem. I believe this problem is fixed in 6.3. Can you confirm?
Weird routing problem on simple CARP setup
Hello, I have a strange problem with OpenBSD 6.2, which looks like a bug. Steps to reproduce : * sh /etc/netstart -> everything works. Routing table : root@fw-t-wan-chut01:~ # netstat -rnf inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.194.119.254 UGS0 16 - 8 bge0 224/4 127.0.0.1 URS0 798 32768 8 lo0 10.194.116/22 10.194.116.29 UCn11 - 4 bge0 10.194.116/22 10.194.116.28 UCn00 -19 carp0 10.194.116.28 00:00:5e:00:01:0f UHLl 03 - 1 carp0 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 28 - 1 bge0 10.194.119.254 00:1b:2a:e9:c4:00 UHLch 25 - 3 bge0 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 1122 32768 1 lo0 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 root@fw-t-wan-chut01:~ # ifconfig carp0 carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0f description: TL-INT-ADM-WAN index 10 priority 15 llprio 3 carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 groups: carp status: master inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 * then sh /etc/netstart carp0 -> routed traffic stops working (ping 10.194.125.120 says "sendmsg: Invalid argument"). Same result if I do ifconfig carp0 10.194.116.28/22. Routing table and ifconfig look the same : root@fw-t-wan-chut01:~ # netstat -rnf inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.194.119.254 UGS5 58 - 8 bge0 224/4 127.0.0.1 URS0 3918 32768 8 lo0 10.194.116/22 10.194.116.29 UCn159014 - 4 bge0 10.194.116/22 10.194.116.28 UCn00 -19 carp0 10.194.116.28 00:00:5e:00:01:0f UHLl 07 - 1 carp0 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 40 - 1 bge0 10.194.119.254 00:1b:2a:e9:c4:00 UHLc 029528 - 3 bge0 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 5498 32768 1 lo0 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 root@fw-t-wan-chut01:~ # ifconfig carp0 carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0f description: TL-INT-ADM-WAN index 10 priority 15 llprio 3 carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 groups: carp status: master inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 * then again sh /etc/netstart -> everything is working again. Deleting and readding the default route also does the trick. If I test something like : root@fw-t-wan-chut01:~ # sh /etc/netstart root@fw-t-wan-chut01:~ # ifconfig bge0 10.194.116.29/22 The default route disappears. This is a bit weird, but at least the routing table is consistent with what happens. I figured a workaround by not using the mygate file, and adding a line in the hostname.bge0 and hostname.carp0 : !route add default 10.194.119.254 1>/dev/null || route change default 10.194.119.254 1>/dev/null Additional informations : Network configuration : root@fw-t-wan-chut01:~ # cat /etc/hostname.bge0
Re: routing problem with wordpress and external and internal traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Op 27-9-2017 om 11:20 schreef Markus Rosjat: > Hi there, > > I have a small problem getting a wordpress instance, that works with ips in the url, to work from the internal net. > > So here ist the setup > > a webserver for some application behind a Openbsd Firewall (webbserver is openBSD 6.0) I have a static ip for my external nic and the wordpress instance uses the external ip in the site url. Additionally I have to use a diffrent port then https because there is a proxy server listining for some other application. > > While reaching the site from the outsite world is no problem because its simple redirect to the webserver and the wordpress instance has the url saved it becomes kinda tricky to reach the wordpress instance from the inside. in the internal net the webserver is listens on port 80 and 443 so I can reach it from the inside but then the wordpress instance is rewiriting the url to a port that isnt 443 becuase from the outsideworld it expects a diffrent port. > > So question now is, is it possible to route the way from inside to the outside and back without inventing the wheel new or is it simpler just to let the webserver listen to the diffrent port too? > > I hope it makes sense to someone to give me a push in the right direction > > regards > Hi, I think you are looking for something along the lines like: match in on $vlan1 proto tcp from any to $realoutside port 443 rdr-to $misp port 443 vlan1 is an inside network, and misp is an internal machine (was reachable from the outside and needed to be reachable on the inside as well). Am I correct? Regards, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZy814AAoJEAeixT/cUIgnicQP/0+bYFH04K3ZagwfTi22NjMN 0txdUlLJCIJtRVaeLFJ4u7MDCKC9CzJO6s7NIwBmwKmaE40fL+itWAJH/qQ1DRQ3 uyG8AlccGLS+KnjNze7zR3rDPMsJFrgtOKVAU0YRNYEFxS0ShYBzme8ZydAwxq7M Br/RxTHEA1kV0kfYk7z1JffdjYkGPpZG9/ocwdVKiwKBOf0LAz8OrlAwEhDcjd/B jWs/T6GkFNDUo1qS1kmRpwXGIHCGjNdz9k1y3kaZ0lz2htt5ITfya1+d09kFNtaB N/OIOwj2mLF6WnJrQ/RDmqEDzIX74XUROH7a1hKJpIhDU8yVRgva/czR5CCkOz+m xwEKESeXhhccOF1aCmY/K3btK0LuBxQqxg48T0XiWeSFyK0V4+nMy4Ddohfuvoll xyYt225XIWB+9hgNOTuChtuy7hKltj8Lv3dyTrNxkRRd/VFF2d0hm/e4FB3NLdFJ 9SwfeOp/NJ33vc3Z0ohx8589sWfL47IleEQWxEBebVE8uQQI/d+bygDa/HhUaB+W P1jzETwHeis/SrIp7wShWC600lCsoNLWvcMHrR0Yu2oCNJsUsbwYvs7SmBIvYBty F6GVpP4Y62hwbHWIL/nALdJSUF6r0GDsn+Gd1DLxQ6ZzP++bBScq93zdW0VXsIxo 3/vQdsjNd6uhh7JwhiXW =XXdi -END PGP SIGNATURE-
Re: routing problem with wordpress and external and internal traffic
hi, Am 27.09.2017 um 15:59 schrieb x9p: I am supposing its Apache because you did not said so. no it's of course a httpd from OpenBSD You are right, httpd. my bad. I am used to Linux world. the problem here is the for internal traffic to somehow rewirite the url to a internal ip with some lines in the server part of the httpd.conf (dont know if this is possible) We know packets are being changed by pf rules when coming from outside world. From inside network, there is a URL transformation that represents the problem are facing . well if I do stuff on the internal nic I could do things to these packages too but this should be the smaller problem here. where is the URL rewrite being done? .htaccess or in another part? I believe this is the first step to search for. If it is in the .htaccess, that is the simpler solution in my point of view. well since .htaccess has nothing to do with httpd of Openbsd rewrites could be possible in relayd (maybe) od as I stated maybe in the sever definition in httpd.conf. or to somehow get the traffic rerouted wen it hits the firewall in a pf rule or rules I believe mix routing/pf rules with URL rewriting makes the problem complex, should be a simple solution. cheers. x9p regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: routing problem with wordpress and external and internal traffic
>> I am supposing its Apache because you did not said so. >> > > no it's of course a httpd from OpenBSD > You are right, httpd. my bad. I am used to Linux world. > the problem here is the for internal traffic to somehow rewirite the > url to a internal ip with some lines in the server part of the > httpd.conf (dont know if this is possible) > We know packets are being changed by pf rules when coming from outside world. From inside network, there is a URL transformation that represents the problem are facing . where is the URL rewrite being done? .htaccess or in another part? I believe this is the first step to search for. If it is in the .htaccess, that is the simpler solution in my point of view. > or to somehow get the traffic rerouted wen it hits the firewall in a pf > rule or rules I believe mix routing/pf rules with URL rewriting makes the problem complex, should be a simple solution. cheers. x9p
Re: routing problem with wordpress and external and internal traffic
Hi, Am 27.09.2017 um 13:33 schrieb x9p: Hi there, Hi I have a small problem getting a wordpress instance, that works with ips in the url, to work from the internal net. So here ist the setup a webserver for some application behind a Openbsd Firewall (webbserver is openBSD 6.0) I have a static ip for my external nic and the wordpress I am supposing its Apache because you did not said so. no it's of course a httpd from OpenBSD So question now is, is it possible to route the way from inside to the outside and back without inventing the wheel new or is it simpler just to let the webserver listen to the diffrent port too? I hope it makes sense to someone to give me a push in the right direction I think its lacking some information, but supposing your wordpress installation is redirecting based on .htaccess rules under httpd I would include a rule to not rewrite the URL based on source IP (if internal, do not apply .htaccess rule of URL rewrite) the problem here is the for internal traffic to somehow rewirite the url to a internal ip with some lines in the server part of the httpd.conf (dont know if this is possible) or to somehow get the traffic rerouted wen it hits the firewall in a pf rule or rules something like: https://unix.stackexchange.com/questions/44129/conditional-directoryindex-based-on-ip-address-using-htaccess cheers. x9p regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: routing problem with wordpress and external and internal traffic
> Hi there, Hi > > I have a small problem getting a wordpress instance, that works with ips > in the url, to work from the internal net. > > So here ist the setup > > a webserver for some application behind a Openbsd Firewall (webbserver > is openBSD 6.0) I have a static ip for my external nic and the wordpress I am supposing its Apache because you did not said so. > So question now is, is it possible to route the way from inside to the > outside and back without inventing the wheel new or is it simpler just > to let the webserver listen to the diffrent port too? > > I hope it makes sense to someone to give me a push in the right direction > I think its lacking some information, but supposing your wordpress installation is redirecting based on .htaccess rules under httpd I would include a rule to not rewrite the URL based on source IP (if internal, do not apply .htaccess rule of URL rewrite) something like: https://unix.stackexchange.com/questions/44129/conditional-directoryindex-based-on-ip-address-using-htaccess cheers. x9p
routing problem with wordpress and external and internal traffic
Hi there, I have a small problem getting a wordpress instance, that works with ips in the url, to work from the internal net. So here ist the setup a webserver for some application behind a Openbsd Firewall (webbserver is openBSD 6.0) I have a static ip for my external nic and the wordpress instance uses the external ip in the site url. Additionally I have to use a diffrent port then https because there is a proxy server listining for some other application. While reaching the site from the outsite world is no problem because its simple redirect to the webserver and the wordpress instance has the url saved it becomes kinda tricky to reach the wordpress instance from the inside. in the internal net the webserver is listens on port 80 and 443 so I can reach it from the inside but then the wordpress instance is rewiriting the url to a port that isnt 443 becuase from the outsideworld it expects a diffrent port. So question now is, is it possible to route the way from inside to the outside and back without inventing the wheel new or is it simpler just to let the webserver listen to the diffrent port too? I hope it makes sense to someone to give me a push in the right direction regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: vmd: routing problem
Hetzner routes additional subnets through a specified mac address on robots page. ( Some cases you need to open a trouble ticket ) Also, all related information is provided there. Cheers, 2017-07-25 10:26 GMT-03:00 Stuart Henderson : > On 2017-07-20, Mike Larkin wrote: > > On Thu, Jul 20, 2017 at 02:19:29PM +0200, Leo Unglaub wrote: > >> Hey, > >> > >> On 07/20/17 13:05, Mischa Peters wrote: > >> > Can you ask them how they route the separate subnet to you? > >> > >> as far as i understand it they route the subnet on my main ip address. > >> > >> > >> From there documentation: > >> > Newly assigned IPv4 subnets are statically routed on the main IP > address of the server, so no gateway is required. > >> > >> I hope that answers your question. > >> Thanks and greetings > >> Leo > > > > > > Like I said before, I'm not a networking expert, but what you've said > there > > doesn't make sense (at least to me). You'll probably need to explain to > them > > what you are trying to do and have them help you. I don't think this is > a vmd > > related network issue. > > It's a common setup at large-scale colo hosts to conserve IP addresses > while > still keeping each customer on their own L2 network. Given a gateway > address > of 192.0.2.1 you should be able to use something like this: > > route add -inet 192.0.2.1/32 -link -iface em0 > route add -inet default 192.0.2.1 > > To run these commands automatically at boot, you can prefix the lines > with ! and add them to hostname.em0. > > >
Re: vmd: routing problem
On 2017-07-20, Mike Larkin wrote: > On Thu, Jul 20, 2017 at 02:19:29PM +0200, Leo Unglaub wrote: >> Hey, >> >> On 07/20/17 13:05, Mischa Peters wrote: >> > Can you ask them how they route the separate subnet to you? >> >> as far as i understand it they route the subnet on my main ip address. >> >> >> From there documentation: >> > Newly assigned IPv4 subnets are statically routed on the main IP address >> > of the server, so no gateway is required. >> >> I hope that answers your question. >> Thanks and greetings >> Leo > > > Like I said before, I'm not a networking expert, but what you've said there > doesn't make sense (at least to me). You'll probably need to explain to them > what you are trying to do and have them help you. I don't think this is a vmd > related network issue. It's a common setup at large-scale colo hosts to conserve IP addresses while still keeping each customer on their own L2 network. Given a gateway address of 192.0.2.1 you should be able to use something like this: route add -inet 192.0.2.1/32 -link -iface em0 route add -inet default 192.0.2.1 To run these commands automatically at boot, you can prefix the lines with ! and add them to hostname.em0.
Re: vmd: routing problem
On Thu, Jul 20, 2017 at 02:19:29PM +0200, Leo Unglaub wrote: > Hey, > > On 07/20/17 13:05, Mischa Peters wrote: > > Can you ask them how they route the separate subnet to you? > > as far as i understand it they route the subnet on my main ip address. > > > From there documentation: > > Newly assigned IPv4 subnets are statically routed on the main IP address of > > the server, so no gateway is required. > > I hope that answers your question. > Thanks and greetings > Leo Like I said before, I'm not a networking expert, but what you've said there doesn't make sense (at least to me). You'll probably need to explain to them what you are trying to do and have them help you. I don't think this is a vmd related network issue. -ml
Re: vmd: routing problem
> What would be the difference to your version where i use vether instead of > an alias? Or did i missunderstand you? > The difference is broadcast trafic won't be sent over your provider network.
Re: vmd: routing problem
Hey, On 07/20/17 09:46, Denis Fondras wrote: Can you people see something that i might missed? The easy way would be enable forwarding, add a vether(4) on the host, bridge it with tap0 and configure it with an IP in the 136.243.186.160/29 subnet. Use that IP as the gateway in your VMs. i did a try where i did the following: 1: I enabled forwarding. 2: I added one IP from the 136.243.186.160/29 subnet as an alias to the main interface of the host 3: I added the main interface em0 and the by vmd created tap0 to a bridge0 4: I tryed to assign the same IP as the alias on em0 to the virtual machine. What would be the difference to your version where i use vether instead of an alias? Or did i missunderstand you? Thanks and greetings Leo
Re: vmd: routing problem
Hey, On 07/20/17 13:05, Mischa Peters wrote: Can you ask them how they route the separate subnet to you? as far as i understand it they route the subnet on my main ip address. From there documentation: Newly assigned IPv4 subnets are statically routed on the main IP address of the server, so no gateway is required. I hope that answers your question. Thanks and greetings Leo
Re: vmd: routing problem
Hi Leo, Can you ask them how they route the separate subnet to you? Mischa > On 20 Jul 2017, at 12:59, Leo Unglaub wrote: > > Hey, > >> On 07/20/17 06:25, Mike Larkin wrote: >> sysctl net.inet.ip.forwarding=1 ? >> I'm not a networking expert but I think your VM's subnet mask is wrong for >> the gateway you are trying to use. > > thank you for your response. I tryed it with net.inet.ip.forwarding being 1 > and 0. Both don't work. About the subnet, thats what confuses me as well, but > the data center tells me that it is correct. As far as i understand it they > do some crazy stuff there with there IPv4 routing: > > https://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en#Subnets > > Thanks and greetings > Leo >
Re: vmd: routing problem
Hey, On 07/20/17 06:25, Mike Larkin wrote: sysctl net.inet.ip.forwarding=1 ? I'm not a networking expert but I think your VM's subnet mask is wrong for the gateway you are trying to use. thank you for your response. I tryed it with net.inet.ip.forwarding being 1 and 0. Both don't work. About the subnet, thats what confuses me as well, but the data center tells me that it is correct. As far as i understand it they do some crazy stuff there with there IPv4 routing: https://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en#Subnets Thanks and greetings Leo
Re: vmd: routing problem
Hello, > Can you people see something that i might missed? The easy way would be enable forwarding, add a vether(4) on the host, bridge it with tap0 and configure it with an IP in the 136.243.186.160/29 subnet. Use that IP as the gateway in your VMs.
Re: vmd: routing problem
Hi List,
Hetzner has like other dedicated hosting providers an "crazy" looking
network setup for ipv4. Here point to point for the default gw in a
different network segment.
So it's important also to keep that in mind.
Maybe this document helps a bit, need to adapt to Openbsd.
https://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_aus_Subnetz/en
Cheers
Karsten
Am 20.07.2017 6:29 vorm. schrieb "Mike Larkin" :
On Thu, Jul 20, 2017 at 04:23:40AM +0200, Leo Unglaub wrote:
> Hey friends,
> i am trying out vmd and I have a little problem getting networking going
> inside the guest machine. I am not sure if this is a problem in vmd or
> simply my misconfiguration.
>
> From my datacenter i got the following data:
>
> Main Server (OpenBSD GENERIC.MP#99 amd64)
> #
> IP: 144.76.102.204
> Netmask: 255.255.255.224
> Gateway: 144.76.102.193
>
>
> Virtual Machine (OpenBSD GENERIC.MP#99 amd64)
> #
> I got an entire subnet from the datacenter. 136.243.186.160/29 So i
decided
> to use the following IP in it.
>
> IP: 136.243.186.161
> Netmask: 255.255.255.248
> Gateway: 144.76.102.204
>
>
> According to there documentation they always route all subnets on the main
> IP. In my case 144.76.102.204.
>
>
> On my host I configured the em0 interface according to the datacenter data
> and it works fine. The host who runs vmd is connected correctly. In my
> /etc/vm.conf i created a switch called "uplink" and added em0 to it. When
i
> check the current config via ifconfig i get the following.
>
> > em0: flags=8b43
mtu 1500
> > lladdr 90:1b:0e:8b:0f:34
> > description: hetzner-uplink
> > index 1 priority 0 llprio 3
> > groups: egress
> > media: Ethernet autoselect (1000baseT
full-duplex,rxpause,txpause)
> > status: active
> > inet 144.76.102.204 netmask 0xffe0 broadcast 144.76.102.223
> >
> >
> > tap0: flags=8943 mtu
1500
> > lladdr fe:e1:ba:d0:7e:0a
> > description: vm1-if0-foobar
> > index 5 priority 0 llprio 3
> > groups: tap
> > status: active
> >
> > bridge0: flags=41
> > description: switch1-uplink
> > index 7 llprio 3
> > groups: bridge
> > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6
proto rstp
> > em0 flags=3
> > port 1 ifpriority 0 ifcost 0
> > tap0 flags=3
> > port 5 ifpriority 0 ifcost 0
> > Addresses (max cache: 100, timeout: 240):
> > 0c:86:10:ed:35:58 em0 1 flags=0<>
>
> My /etc/vm.conf looks like this:
>
> > switch "uplink" {
> > add em0
> > }
> >
> > vm "foobar" {
> > memory 2G
> > disk "/tmp/1.vdi"
> > interface {
> > switch "uplink"
> > }
> > }
>
> When i start the vm with my current /bsd.rd i start the installer and
insert
> the following:
>
> > Available network interfaces are: vio0 vlan0.
> > Which network interface do you wish to configure? (or 'done') [vio0]
> > IPv4 address for vio0? (or 'dhcp' or 'none') [dhcp] 136.243.186.161
> > Netmask for vio0? [255.255.255.248] IPv6 address for vio0? (or
> > 'autoconf' or 'none') [none] Available network interfaces are: vio0
> > vlan0.
> > Which network interface do you wish to configure? (or 'done') [done]
> > Default IPv4 route? (IPv4 address or none) 144.76.102.204
> > add net default: gateway 144.76.102.204: Network is unreachable
>
> Can you people see something that i might missed?
> Big thanks in advance and greetings
> Leo
>
>
sysctl net.inet.ip.forwarding=1 ?
I'm not a networking expert but I think your VM's subnet mask is wrong for
the gateway you are trying to use.
-ml
Re: vmd: routing problem
On Thu, Jul 20, 2017 at 04:23:40AM +0200, Leo Unglaub wrote:
> Hey friends,
> i am trying out vmd and I have a little problem getting networking going
> inside the guest machine. I am not sure if this is a problem in vmd or
> simply my misconfiguration.
>
> From my datacenter i got the following data:
>
> Main Server (OpenBSD GENERIC.MP#99 amd64)
> #
> IP: 144.76.102.204
> Netmask: 255.255.255.224
> Gateway: 144.76.102.193
>
>
> Virtual Machine (OpenBSD GENERIC.MP#99 amd64)
> #
> I got an entire subnet from the datacenter. 136.243.186.160/29 So i decided
> to use the following IP in it.
>
> IP: 136.243.186.161
> Netmask: 255.255.255.248
> Gateway: 144.76.102.204
>
>
> According to there documentation they always route all subnets on the main
> IP. In my case 144.76.102.204.
>
>
> On my host I configured the em0 interface according to the datacenter data
> and it works fine. The host who runs vmd is connected correctly. In my
> /etc/vm.conf i created a switch called "uplink" and added em0 to it. When i
> check the current config via ifconfig i get the following.
>
> > em0: flags=8b43
> > mtu 1500
> > lladdr 90:1b:0e:8b:0f:34
> > description: hetzner-uplink
> > index 1 priority 0 llprio 3
> > groups: egress
> > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
> > status: active
> > inet 144.76.102.204 netmask 0xffe0 broadcast 144.76.102.223
> >
> >
> > tap0: flags=8943 mtu 1500
> > lladdr fe:e1:ba:d0:7e:0a
> > description: vm1-if0-foobar
> > index 5 priority 0 llprio 3
> > groups: tap
> > status: active
> >
> > bridge0: flags=41
> > description: switch1-uplink
> > index 7 llprio 3
> > groups: bridge
> > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto
> > rstp
> > em0 flags=3
> > port 1 ifpriority 0 ifcost 0
> > tap0 flags=3
> > port 5 ifpriority 0 ifcost 0
> > Addresses (max cache: 100, timeout: 240):
> > 0c:86:10:ed:35:58 em0 1 flags=0<>
>
> My /etc/vm.conf looks like this:
>
> > switch "uplink" {
> > add em0
> > }
> >
> > vm "foobar" {
> > memory 2G
> > disk "/tmp/1.vdi"
> > interface {
> > switch "uplink"
> > }
> > }
>
> When i start the vm with my current /bsd.rd i start the installer and insert
> the following:
>
> > Available network interfaces are: vio0 vlan0.
> > Which network interface do you wish to configure? (or 'done') [vio0]
> > IPv4 address for vio0? (or 'dhcp' or 'none') [dhcp] 136.243.186.161
> > Netmask for vio0? [255.255.255.248] IPv6 address for vio0? (or
> > 'autoconf' or 'none') [none] Available network interfaces are: vio0
> > vlan0.
> > Which network interface do you wish to configure? (or 'done') [done]
> > Default IPv4 route? (IPv4 address or none) 144.76.102.204
> > add net default: gateway 144.76.102.204: Network is unreachable
>
> Can you people see something that i might missed?
> Big thanks in advance and greetings
> Leo
>
>
sysctl net.inet.ip.forwarding=1 ?
I'm not a networking expert but I think your VM's subnet mask is wrong for
the gateway you are trying to use.
-ml
vmd: routing problem
Hey friends,
i am trying out vmd and I have a little problem getting networking going
inside the guest machine. I am not sure if this is a problem in vmd or
simply my misconfiguration.
From my datacenter i got the following data:
Main Server (OpenBSD GENERIC.MP#99 amd64)
#
IP: 144.76.102.204
Netmask: 255.255.255.224
Gateway: 144.76.102.193
Virtual Machine (OpenBSD GENERIC.MP#99 amd64)
#
I got an entire subnet from the datacenter. 136.243.186.160/29 So i
decided to use the following IP in it.
IP: 136.243.186.161
Netmask: 255.255.255.248
Gateway: 144.76.102.204
According to there documentation they always route all subnets on the
main IP. In my case 144.76.102.204.
On my host I configured the em0 interface according to the datacenter
data and it works fine. The host who runs vmd is connected correctly. In
my /etc/vm.conf i created a switch called "uplink" and added em0 to it.
When i check the current config via ifconfig i get the following.
em0: flags=8b43 mtu
1500
lladdr 90:1b:0e:8b:0f:34
description: hetzner-uplink
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 144.76.102.204 netmask 0xffe0 broadcast 144.76.102.223
tap0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:7e:0a
description: vm1-if0-foobar
index 5 priority 0 llprio 3
groups: tap
status: active
bridge0: flags=41
description: switch1-uplink
index 7 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
em0 flags=3
port 1 ifpriority 0 ifcost 0
tap0 flags=3
port 5 ifpriority 0 ifcost 0
Addresses (max cache: 100, timeout: 240):
0c:86:10:ed:35:58 em0 1 flags=0<>
My /etc/vm.conf looks like this:
switch "uplink" {
add em0
}
vm "foobar" {
memory 2G
disk "/tmp/1.vdi"
interface {
switch "uplink"
}
}
When i start the vm with my current /bsd.rd i start the installer and
insert the following:
Available network interfaces are: vio0 vlan0.
Which network interface do you wish to configure? (or 'done') [vio0]
IPv4 address for vio0? (or 'dhcp' or 'none') [dhcp] 136.243.186.161
Netmask for vio0? [255.255.255.248]
IPv6 address for vio0? (or 'autoconf' or 'none') [none]
Available network interfaces are: vio0 vlan0.
Which network interface do you wish to configure? (or 'done') [done]
Default IPv4 route? (IPv4 address or none) 144.76.102.204
add net default: gateway 144.76.102.204: Network is unreachable
Can you people see something that i might missed?
Big thanks in advance and greetings
Leo
Re: Pf routing problem
On 2012-05-02 21:56:39 -0300, Leonardo M. Rami wrote: > On 2012-05-02 23:27:44 +0200, Claudio Jeker wrote: > > On Wed, May 02, 2012 at 03:26:20PM -0300, Leonardo M. Rami wrote: > > > Hi, I've posted this to ServerFault.com, and I got an answer, but the > > > solution works only in part. > > > > > > This is my /etc/pf.conf > > > > > > set skip on lo > > > pass in log on em0 proto tcp from any to any port 104 rdr-to > > > 192.65.214.131 > > > pass out on vic0 from em0:network to any nat-to vic0 > > > > > > I have two nics: > > > > > > vic0 192.65.214.136 > > > em0 192.168.200.3 > > > > > > What I want to do is to forward all packets comming into 192.168.200.3 > > > port 104 to 192.65.214.131 port 104. > > > > > > The above configuration works perfectly if the sender interface is in > > > the network 192.168.200.x, but I also must allow packets comming from > > > other networks, like 192.168.7.x, for example. > > > > > > How can I enable them?. > > > > > > > With these redir rules redirection should just work but only in the case > > where the reverse traffic is also hitting the FW. If that is not the case > > I normaly tag the inbound traffic and use a tagged foobar nat-to ($out_if) > > statement to not only redir but also nat the traffic. With that I can > > ensure that the return traffic is flowing through the FW. > > > > Thanks Claudio, could you give an example?. > Well I don't know why this didn't work, but suddenly, after fiddling with tcpdup it started to work as I expected. This is my new /etc/pf.conf: - ext_if = "em0" int_if = "em1" set skip on lo pass in on $ext_if proto tcp from any to any port 104 rdr-to 192.65.214.131 pass out on $int_if from $ext_if:network to any nat-to $int_if block in on ! lo0 proto tcp to port 6000:6010 - My interfaces are as this: # cat /etc/hostname.em0 inet 192.168.200.3 255.255.255.0 NONE inet alias 192.168.7.3 255.255.255.0 # cat /etc/hostname.em1 inet 192.65.214.136 255.255.255.0 NONE -- Leonardo M. Rami Medical IT - Griensu S.A. Av. Colsn 636 - Piso 8 Of. A X5000EPT -- Csrdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54(351)156629292
Re: Pf routing problem
On 2012-05-02 23:27:44 +0200, Claudio Jeker wrote: > On Wed, May 02, 2012 at 03:26:20PM -0300, Leonardo M. Rami wrote: > > Hi, I've posted this to ServerFault.com, and I got an answer, but the > > solution works only in part. > > > > This is my /etc/pf.conf > > > > set skip on lo > > pass in log on em0 proto tcp from any to any port 104 rdr-to 192.65.214.131 > > pass out on vic0 from em0:network to any nat-to vic0 > > > > I have two nics: > > > > vic0 192.65.214.136 > > em0 192.168.200.3 > > > > What I want to do is to forward all packets comming into 192.168.200.3 > > port 104 to 192.65.214.131 port 104. > > > > The above configuration works perfectly if the sender interface is in > > the network 192.168.200.x, but I also must allow packets comming from > > other networks, like 192.168.7.x, for example. > > > > How can I enable them?. > > > > With these redir rules redirection should just work but only in the case > where the reverse traffic is also hitting the FW. If that is not the case > I normaly tag the inbound traffic and use a tagged foobar nat-to ($out_if) > statement to not only redir but also nat the traffic. With that I can > ensure that the return traffic is flowing through the FW. > Thanks Claudio, could you give an example?. Regards, -- Leonardo M. Rami Medical IT - Griensu S.A. Av. Colsn 636 - Piso 8 Of. A X5000EPT -- Csrdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54(351)156629292
Re: Pf routing problem
On Wed, May 02, 2012 at 03:26:20PM -0300, Leonardo M. Rami wrote: > Hi, I've posted this to ServerFault.com, and I got an answer, but the > solution works only in part. > > This is my /etc/pf.conf > > set skip on lo > pass in log on em0 proto tcp from any to any port 104 rdr-to 192.65.214.131 > pass out on vic0 from em0:network to any nat-to vic0 > > I have two nics: > > vic0 192.65.214.136 > em0 192.168.200.3 > > What I want to do is to forward all packets comming into 192.168.200.3 > port 104 to 192.65.214.131 port 104. > > The above configuration works perfectly if the sender interface is in > the network 192.168.200.x, but I also must allow packets comming from > other networks, like 192.168.7.x, for example. > > How can I enable them?. > With these redir rules redirection should just work but only in the case where the reverse traffic is also hitting the FW. If that is not the case I normaly tag the inbound traffic and use a tagged foobar nat-to ($out_if) statement to not only redir but also nat the traffic. With that I can ensure that the return traffic is flowing through the FW. -- :wq Claudio
Pf routing problem
Hi, I've posted this to ServerFault.com, and I got an answer, but the solution works only in part. This is my /etc/pf.conf set skip on lo pass in log on em0 proto tcp from any to any port 104 rdr-to 192.65.214.131 pass out on vic0 from em0:network to any nat-to vic0 I have two nics: vic0 192.65.214.136 em0 192.168.200.3 What I want to do is to forward all packets comming into 192.168.200.3 port 104 to 192.65.214.131 port 104. The above configuration works perfectly if the sender interface is in the network 192.168.200.x, but I also must allow packets comming from other networks, like 192.168.7.x, for example. How can I enable them?. Regards, -- Leonardo M. Rami Medical IT - Griensu S.A. Av. Colsn 636 - Piso 8 Of. A X5000EPT -- Csrdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54(351)156629292
Re: routing problem
On Wed, 28 Sep 2011 15:42:05 +0400, pavel pocheptsov wrote: > 28 QP5P=QQP1QQ 2011, 15:28 P>Q "Wesley M." : >> The VPN is between a fictif ip address(gives by the_green_bow) to >> 10.100.1.0/24 >> >> Using VPN, i can ping 10.100.1.250 and use also ssh on the box but pings >> doesn't work for : 10.100.1.100, and 10.100.1.254. >> >> On the OpenBSD SIDE : ipsec.conf >> >> ike dynamic from 10.100.1.0/24 to any \ >> main auth hmac-sha1 enc aes-256 group modp1024 \ >> quick auth hmac-sha1 enc aes-256 psk demokey >> > maybe add to ipsec.conf "from any to 10.100.." I don't think that it will solve my mistake. Because VPN works, and ready to 10.100.1.0/24 The problem is that the server 10.100.1.100 has a different gateway (10.100.1.254) > on remote side "route add 10.100.1.0 mask 255.255.255.0 > IP_addres_of_your_vpn_gateway(not real gateway)" it doesn't work. :-(
Re[2]: routing problem
28 QP5P=QQP1QQ 2011, 15:28 P>Q "Wesley M." : > The VPN is between a fictif ip address(gives by the_green_bow) to > 10.100.1.0/24 > > Using VPN, i can ping 10.100.1.250 and use also ssh on the box but pings > doesn't work for : 10.100.1.100, and 10.100.1.254. > > On the OpenBSD SIDE : ipsec.conf > > ike dynamic from 10.100.1.0/24 to any \ > main auth hmac-sha1 enc aes-256 group modp1024 \ > quick auth hmac-sha1 enc aes-256 psk demokey > maybe add to ipsec.conf "from any to 10.100.." on remote side "route add 10.100.1.0 mask 255.255.255.0 IP_addres_of_your_vpn_gateway(not real gateway)"
Re: routing problem
On 2011-09-28, Wesley M. wrote: >> Fixes: 1) fix the default gateway on the TS Server machine, add a custom >> route for whatever that "private network" thingie is. > > I can't change the gateway, because the others locations (there are 4) > won't connect on TS. You could add a custom static route for the private network behind the IPsec gateway, though.
Re: routing problem
On 2011-09-28, Nick Holland wrote:
> On 09/28/11 03:13, Wesley M. wrote:
>> Hi,
>>
>> I have at work:
>> TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for private
>> network)
>
> bzzt. Bad.
> (I'm guessing that's a windows terminal server)
>
>> Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
>> :sis2
>>
>> On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389 ->
>> OK
>
> right. no gateway involved.
>
>> When i am at home, i connect to firewall using "thegreenbow" vpn is ok, i
>> can ping 10.100.1.250, use ssh on the firewall, but i can't ping
>> 10.100.1.100 and can't use rdp on this address.
>>
>> my pf rules:
>> ...
>> set skip on {lo,enc0}
>> pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
>> pass out inet proto icmp all icmp-type echoreq
>> ...
>
> because your packets come from your machine, through your firewall, to
> the "TS Server", but they are still "off-network" packets. When it
> responds to an off-network address, it routes them to the gateway
> machine...which is 10.100.1.254, not the firewall.
>
> Fixes: 1) fix the default gateway on the TS Server machine, add a custom
> route for whatever that "private network" thingie is.
> 2) instead of your VPN, use an SSH tunnel to your firewall, then
> redirect 3389 to the TS Server. This way, your remote desktop session
> is between the gateway and the firewall, which are both on the same subnet.
or 3) nat the vpn traffic..
Re: routing problem
The VPN is between a fictif ip address(gives by the_green_bow) to
10.100.1.0/24
Using VPN, i can ping 10.100.1.250 and use also ssh on the box but pings
doesn't work for : 10.100.1.100, and 10.100.1.254.
On the OpenBSD SIDE : ipsec.conf
ike dynamic from 10.100.1.0/24 to any \
main auth hmac-sha1 enc aes-256 group modp1024 \
quick auth hmac-sha1 enc aes-256 psk demokey
On Wed, 28 Sep 2011 15:05:52 +0400, pavel pocheptsov
wrote:
> what settings on client/home side?
> B ipconfig /all, route print..etc
>
>
> 28 QP5P=QQP1QQ 2011, 11:18 P>Q "Wesley M."
:
>
>
>
>
> Hi,
>
> I have at work:
> TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for private
> network)
> Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
> :sis2
>
> On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389 ->
> OK
>
> When i am at home, i connect to firewall using "thegreenbow" vpn is ok,
i
> can ping 10.100.1.250, use ssh on the firewall, but i can't ping
> 10.100.1.100 and can't use rdp on this address.
>
> my pf rules:
> ...
> set skip on {lo,enc0}
> pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
> pass out inet proto icmp all icmp-type echoreq
> ...
>
> Any idea ?
> thank you very much.
> Wesley
Re: routing problem
On Wed, 28 Sep 2011 06:49:59 -0400, Nick Holland
wrote:
> On 09/28/11 03:13, Wesley M. wrote:
>> Hi,
>>
>> I have at work:
>> TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for
private
>> network)
>
> bzzt. Bad.
> (I'm guessing that's a windows terminal server)
Yes, it is (RDS, Windows 2008 R2)
>> Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
>> :sis2
>>
>> On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389
->
>> OK
>
> right. no gateway involved.
Yes, it doesn't need the gateway : 10.100.1.254
>
>> When i am at home, i connect to firewall using "thegreenbow" vpn is ok,
i
>> can ping 10.100.1.250, use ssh on the firewall, but i can't ping
>> 10.100.1.100 and can't use rdp on this address.
>>
>> my pf rules:
>> ...
>> set skip on {lo,enc0}
>> pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
>> pass out inet proto icmp all icmp-type echoreq
>> ...
>
To resume :
INTERNET---sis0-sis1---LAN---
On the LAN side :
There's the TS SERVER and the ISP ROUTER (need it to connect the 4 others
locations)
>
> Fixes: 1) fix the default gateway on the TS Server machine, add a custom
> route for whatever that "private network" thingie is.
I can't change the gateway, because the others locations (there are 4)
won't connect on TS.
> 2) instead of your VPN, use an SSH tunnel to your firewall, then
> redirect 3389 to the TS Server. This way, your remote desktop session
> is between the gateway and the firewall, which are both on the same
subnet.
Seem's a good solution. But there's no other way to connect TS using VPN ?
>
> Nick.
Re: routing problem
what settings on client/home side?
B ipconfig /all, route print..etc
28 QP5P=QQP1QQ 2011, 11:18 P>Q "Wesley M." :
Hi,
I have at work:
TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for private
network)
Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
:sis2
On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389 ->
OK
When i am at home, i connect to firewall using "thegreenbow" vpn is ok, i
can ping 10.100.1.250, use ssh on the firewall, but i can't ping
10.100.1.100 and can't use rdp on this address.
my pf rules:
...
set skip on {lo,enc0}
pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
pass out inet proto icmp all icmp-type echoreq
...
Any idea ?
thank you very much.
Wesley
Re: routing problem
On 09/28/11 03:13, Wesley M. wrote:
> Hi,
>
> I have at work:
> TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for private
> network)
bzzt. Bad.
(I'm guessing that's a windows terminal server)
> Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
> :sis2
>
> On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389 ->
> OK
right. no gateway involved.
> When i am at home, i connect to firewall using "thegreenbow" vpn is ok, i
> can ping 10.100.1.250, use ssh on the firewall, but i can't ping
> 10.100.1.100 and can't use rdp on this address.
>
> my pf rules:
> ...
> set skip on {lo,enc0}
> pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
> pass out inet proto icmp all icmp-type echoreq
> ...
because your packets come from your machine, through your firewall, to
the "TS Server", but they are still "off-network" packets. When it
responds to an off-network address, it routes them to the gateway
machine...which is 10.100.1.254, not the firewall.
Fixes: 1) fix the default gateway on the TS Server machine, add a custom
route for whatever that "private network" thingie is.
2) instead of your VPN, use an SSH tunnel to your firewall, then
redirect 3389 to the TS Server. This way, your remote desktop session
is between the gateway and the firewall, which are both on the same subnet.
Nick.
routing problem
Hi,
I have at work:
TS Server : 10.100.1.100 his gateway is 10.100.1.254 (router for private
network)
Firewall : 10.100.1.250 (OpenBSD 4.9, ADSL : sis0, Lan (10.100.1.0/24)
:sis2
On the firewall, i can ping 10.100.1.100 and telnet 10.100.1.100 3389 ->
OK
When i am at home, i connect to firewall using "thegreenbow" vpn is ok, i
can ping 10.100.1.250, use ssh on the firewall, but i can't ping
10.100.1.100 and can't use rdp on this address.
my pf rules:
...
set skip on {lo,enc0}
pass out on sis2 inet proto tcp from $remote to 10.100.1.100 port 3389
pass out inet proto icmp all icmp-type echoreq
...
Any idea ?
thank you very much.
Wesley
Re: routing problem with 2nd default route via ipsec
IPsec flows take priority over all standard routing table entries, it sounds like you need a bypass flow for the protocol carp traffic if you don't want it to match your IPsec flow. On 2011-07-28, Axel Rau wrote: > Hi all, > > I have a routing firewall, which is also a ipsec client like this: > >ppp uplink (IPv4) > | >dc3|pppoe0 > +++ > |+|dc1 > | enc0 +- DMZ2 > | | > | |dc0 > | +- DMZ1 > | | > +++ > | em0 > Intranet > > DMZ2 has public address space (here named 11.222.33.128/25). Outgoing traffic > from this net should go through the ipsec tunnel. > > IPv4 traffic from Intranet and DMZ1 to none-local and none 11.222.33/24 uses > default route via NAT and pppoe0 as expected. > > What drives me nuts is: All traffic to 11.222.33/24 from em0 and dc1 > (including > all CARP traffic from its carp2) go to enc0, like this: > > 11:10:19.428653 rule 18/(match) [uid 0, pid 15367] block out on enc0: \ > carp 11.222.33.132 > 224.0.0.18: CARPv2-advertise 36: vhid=3 advbase=1 \ > advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 59211, len 56, bad cksum 0!) > > > What's going on here? > > route-to in pf.conf seem of no influence. > > > Encap: > Source Port DestinationPort Proto > > SA(Address/Proto/Type/Direction) > 11.222.33.64/260 172.16.9/240 0 > > 111.222.111.222/esp/use/in > 172.16.9/240 11.222.33.64/260 0 > > 111.222.111.222/esp/require/out > 11.222.33.16/280 192.168.110/24 0 0 > > 111.222.111.222/esp/use/in > 192.168.110/24 0 11.222.33.16/280 0 > > 111.222.111.222/esp/require/out > default0 2001:a12:d:10::/60 0 > > 0 111.222.111.222/esp/use/in > 2001:a12:d:10::/60 0 default0 > > 0 111.222.111.222/esp/require/out > default0 11.222.33.128/25 0 0 > > 111.222.111.222/esp/use/in > 11.222.33.128/25 0 default0 0 > > 111.222.111.222/esp/require/out > 11.222.33.64/260 192.168.110/24 0 0 > > 111.222.111.222/esp/use/in > 192.168.110/24 0 11.222.33.64/260 0 > > 111.222.111.222/esp/require/out > > root# ifconfig dc1 > dc1: flags=8943 mtu 1500 > lladdr 00:80:c8:b9:04:ce > priority: 0 > media: Ethernet autoselect (100baseTX full-duplex) > status: active > inet 11.222.33.132 netmask 0xff80 broadcast 11.222.33.255 > inet6 fe80::280:c8ff:feb9:4ce%dc1 prefixlen 64 scopeid 0x3 > inet6 2001:a12:d:18::b prefixlen 64 > > carp2: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:03 > priority: 0 > carp: MASTER carpdev dc1 vhid 3 advbase 1 advskew 0 > groups: carp > status: master > inet6 fe80::200:5eff:fe00:103%carp2 prefixlen 64 scopeid 0xd > inet 11.222.33.139 netmask 0xff80 broadcast 11.222.33.255 > inet6 2001:a12:d:18::c prefixlen 64 > > This is a GENERIC snapshot from about 2011-06-08. > I have net.inet.ip.multipath=1 > > What am I doing wrong? > Time to start using rdomains / multiple rtables? > > Axel > --- > PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos claudius
Re: routing problem with 2nd default route via ipsec
Am 28.07.2011 um 13:23 schrieb Axel Rau: > all CARP traffic from its carp2) go to enc0, like this: What may cause IPv4 CARP traffic to not go out on its parent device but on enc0 instead? IPv6 CARP and other CARP devises behave as expected. Axel --- PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos claudius
Re: routing problem with 2nd default route via ipsec
Am 28.07.2011 um 16:06 schrieb Gregory Edigarov: > let me guess > I think you just need to allow traffic on enc0 > > set skip on enc0 No, its not that easy. (-; I block carp multicast messages on enc0 and just showed that. A tcpdump on enc0 would have shown the same. The problem is that those multicasts should go out on dc1 not come in. Axel --- PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos claudius
Re: routing problem with 2nd default route via ipsec
On Thu, 28 Jul 2011 13:23:02 +0200 Axel Rau wrote: > Hi all, > > I have a routing firewall, which is also a ipsec client like this: > >ppp uplink (IPv4) > | >dc3|pppoe0 > +++ > |+|dc1 > | enc0 +- DMZ2 > | | > | |dc0 > | +- DMZ1 > | | > +++ > | em0 > Intranet > > DMZ2 has public address space (here named 11.222.33.128/25). Outgoing > traffic from this net should go through the ipsec tunnel. > > IPv4 traffic from Intranet and DMZ1 to none-local and none > 11.222.33/24 uses default route via NAT and pppoe0 as expected. > > What drives me nuts is: All traffic to 11.222.33/24 from em0 and dc1 > (including > all CARP traffic from its carp2) go to enc0, like this: > > 11:10:19.428653 rule 18/(match) [uid 0, pid 15367] block out on enc0: > \ carp 11.222.33.132 > 224.0.0.18: CARPv2-advertise 36: vhid=3 > advbase=1 \ advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 59211, > len 56, bad cksum 0!) > > > What's going on here? > > route-to in pf.conf seem of no influence. let me guess I think you just need to allow traffic on enc0 set skip on enc0 should be enough
routing problem with 2nd default route via ipsec
Hi all, I have a routing firewall, which is also a ipsec client like this: ppp uplink (IPv4) | dc3|pppoe0 +++ |+|dc1 | enc0 +- DMZ2 | | | |dc0 | +- DMZ1 | | +++ | em0 Intranet DMZ2 has public address space (here named 11.222.33.128/25). Outgoing traffic from this net should go through the ipsec tunnel. IPv4 traffic from Intranet and DMZ1 to none-local and none 11.222.33/24 uses default route via NAT and pppoe0 as expected. What drives me nuts is: All traffic to 11.222.33/24 from em0 and dc1 (including all CARP traffic from its carp2) go to enc0, like this: 11:10:19.428653 rule 18/(match) [uid 0, pid 15367] block out on enc0: \ carp 11.222.33.132 > 224.0.0.18: CARPv2-advertise 36: vhid=3 advbase=1 \ advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 59211, len 56, bad cksum 0!) What's going on here? route-to in pf.conf seem of no influence. Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 11.222.33.64/260 172.16.9/240 0 111.222.111.222/esp/use/in 172.16.9/240 11.222.33.64/260 0 111.222.111.222/esp/require/out 11.222.33.16/280 192.168.110/24 0 0 111.222.111.222/esp/use/in 192.168.110/24 0 11.222.33.16/280 0 111.222.111.222/esp/require/out default0 2001:a12:d:10::/60 0 0 111.222.111.222/esp/use/in 2001:a12:d:10::/60 0 default0 0 111.222.111.222/esp/require/out default0 11.222.33.128/25 0 0 111.222.111.222/esp/use/in 11.222.33.128/25 0 default0 0 111.222.111.222/esp/require/out 11.222.33.64/260 192.168.110/24 0 0 111.222.111.222/esp/use/in 192.168.110/24 0 11.222.33.64/260 0 111.222.111.222/esp/require/out root# ifconfig dc1 dc1: flags=8943 mtu 1500 lladdr 00:80:c8:b9:04:ce priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 11.222.33.132 netmask 0xff80 broadcast 11.222.33.255 inet6 fe80::280:c8ff:feb9:4ce%dc1 prefixlen 64 scopeid 0x3 inet6 2001:a12:d:18::b prefixlen 64 carp2: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:03 priority: 0 carp: MASTER carpdev dc1 vhid 3 advbase 1 advskew 0 groups: carp status: master inet6 fe80::200:5eff:fe00:103%carp2 prefixlen 64 scopeid 0xd inet 11.222.33.139 netmask 0xff80 broadcast 11.222.33.255 inet6 2001:a12:d:18::c prefixlen 64 This is a GENERIC snapshot from about 2011-06-08. I have net.inet.ip.multipath=1 What am I doing wrong? Time to start using rdomains / multiple rtables? Axel --- PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos claudius
Re: routing problem
Thank you everyone. I cannot believe I forgot to set up that static route from the DSL modem back to the 10.40.60.0 network. Works like a charm. Next comes ipv6! On Jul 9, 2010, at 2:31 PM, Jussi Peltola wrote: > On Fri, Jul 09, 2010 at 02:19:42PM -0700, Matt S wrote: >> Given the following: >> >> [internet - DSL Modem - 192.168.0.1]--[bge0:192.168.0.254 - OpenBSD >> 4.7 - em0:10.40.60.1]--[Laptop - DHCP] >> >> net.inet.ip.forwarding=1 >> >> How can I get my laptop to reach the internet? I kind of figured that all I >> would have to do is have forwarding enabled on the OpenBSD box without >> specifying any additional routing instructions. I can ping my laptop from >> the OpenBSD box. Since my default gateway is effectively 192.168.0.1, I am >> puzzled as to why I cannot ping that address from the laptop. What could I >> possibly be missing? I'm tearing my hair out . >> > > The modem has no route to 10.40.60.0/[whatever your netmask is, perhaps > you should have included enough information] > > It will reply to this mysterious "internet" where its default route > points. > > This configuration is not guaranteed to work even if you add a static > route in the modem, since it may not nat source addresses not within > 192.168.0.0/[whatever netmask it is]. > > It's probably easiest to nat connections from 10.40.60.1/[...] on the > openbsd box.
Re: routing problem
Am Fri, 9 Jul 2010 14:19:42 -0700 schrieb Matt S : > [internet - DSL Modem - 192.168.0.1]--[bge0:192.168.0.254 - > OpenBSD 4.7 - em0:10.40.60.1]--[Laptop - DHCP] > ping my laptop from the OpenBSD box. Since my default gateway is > effectively 192.168.0.1, I am puzzled as to why I cannot ping that > address from the laptop. Is the default route on your laptop set to 10.40.60.1 ? Does the DSL Modem know how to reach your 10.40.60.1 subnet?
Re: routing problem
On Fri, Jul 09, 2010 at 02:19:42PM -0700, Matt S wrote: > Given the following: > > [internet - DSL Modem - 192.168.0.1]--[bge0:192.168.0.254 - OpenBSD > 4.7 - em0:10.40.60.1]--[Laptop - DHCP] > > net.inet.ip.forwarding=1 > > How can I get my laptop to reach the internet? I kind of figured that all I > would have to do is have forwarding enabled on the OpenBSD box without > specifying any additional routing instructions. I can ping my laptop from > the OpenBSD box. Since my default gateway is effectively 192.168.0.1, I am > puzzled as to why I cannot ping that address from the laptop. What could I > possibly be missing? I'm tearing my hair out . > The modem has no route to 10.40.60.0/[whatever your netmask is, perhaps you should have included enough information] It will reply to this mysterious "internet" where its default route points. This configuration is not guaranteed to work even if you add a static route in the modem, since it may not nat source addresses not within 192.168.0.0/[whatever netmask it is]. It's probably easiest to nat connections from 10.40.60.1/[...] on the openbsd box.
Re: routing problem
On Fri, Jul 09, 2010 at 02:19:42PM -0700, Matt S wrote: > Given the following: > > [internet - DSL Modem - 192.168.0.1]--[bge0:192.168.0.254 - OpenBSD > 4.7 - em0:10.40.60.1]--[Laptop - DHCP] > > net.inet.ip.forwarding=1 > > How can I get my laptop to reach the internet? I kind of figured that all I > would have to do is have forwarding enabled on the OpenBSD box without > specifying any additional routing instructions. I can ping my laptop from > the OpenBSD box. Since my default gateway is effectively 192.168.0.1, I am > puzzled as to why I cannot ping that address from the laptop. What could I > possibly be missing? I'm tearing my hair out . > Simply because the DSL modem has no idea where 10.40.60.1 is and sends it down the DSL pipe. You need to add a route on the modem for this network pointing to you OpenBSD box. If not possible have a look at bridge(4) -- :wq Claudio
routing problem
Given the following: [internet - DSL Modem - 192.168.0.1]--[bge0:192.168.0.254 - OpenBSD 4.7 - em0:10.40.60.1]--[Laptop - DHCP] net.inet.ip.forwarding=1 How can I get my laptop to reach the internet? I kind of figured that all I would have to do is have forwarding enabled on the OpenBSD box without specifying any additional routing instructions. I can ping my laptop from the OpenBSD box. Since my default gateway is effectively 192.168.0.1, I am puzzled as to why I cannot ping that address from the laptop. What could I possibly be missing? I'm tearing my hair out . Thanks, Matt
Re: routing problem
On Fri, Feb 20, 2009 at 6:34 AM, Federico wrote: > Hello all, > > I have a trouble with some routing-related that i can't figure out. > > I have this configuration: > > > ** > ***INTERNET*** > ** > | >bnx1 > | FIREWALL | >bnx0 > | >DMZ (10.0.0.0/28) > | >bnx1 > | PROXY | >bnx0 > | >LAN (192.168.80.0/24) > > > > FIREWALL and PROXY are both OpenBSD machines. > > The bnx1 of the firewall is configured on a public subnet. > > A couple of machines in the DMZ are natted with public ip configured on > the bnx1 of the firewall. > > For a particular reason, I have to route traffic from LAN to DMZ using > the pubblic ip. I can't use a DNS based solution (like views). So, when > I try to connect to a DMZ machine by using its pubblic (natted) ip, > traffic is blocked at bnx0 of the firewall. > > With tcpdump I can see that bnx0 answers with a RST packet to the > connection request coming from lan (and masked by PROXY). > > The only "trick" I found to make it works, is using redirect on PROXY, > something like that: > > rdr on bnx1 from bnx0:network to $MyPublicIp -> 10.0.0.2 > > This is the basic ruleset I'm using on FIREWALL: > > set skip on lo > scrub in > rdr pass on bnx1 proto tcp from any to $MyPublicIP port 80 -> 10.0.0.2 > block in log > pass out > pass in on bnx1 proto tcp from any to 10.0.0.2 port 80 flags S/SA > synproxy state > > I didn't touch routes. > > Is there another way than using a set of rdr rules? Did I miss some man > page? $MyPublicIP doesn't actually belong to your DMZ machine, so FIREWALL's route to that address (if it has one) is not what you're expecting. Your rdr on PROXY solves the problem. Use it or remove the need for it. -HKS
routing problem
Hello all, I have a trouble with some routing-related that i can't figure out. I have this configuration: ** ***INTERNET*** ** | bnx1 | FIREWALL | bnx0 | DMZ (10.0.0.0/28) | bnx1 | PROXY | bnx0 | LAN (192.168.80.0/24) FIREWALL and PROXY are both OpenBSD machines. The bnx1 of the firewall is configured on a public subnet. A couple of machines in the DMZ are natted with public ip configured on the bnx1 of the firewall. For a particular reason, I have to route traffic from LAN to DMZ using the pubblic ip. I can't use a DNS based solution (like views). So, when I try to connect to a DMZ machine by using its pubblic (natted) ip, traffic is blocked at bnx0 of the firewall. With tcpdump I can see that bnx0 answers with a RST packet to the connection request coming from lan (and masked by PROXY). The only "trick" I found to make it works, is using redirect on PROXY, something like that: rdr on bnx1 from bnx0:network to $MyPublicIp -> 10.0.0.2 This is the basic ruleset I'm using on FIREWALL: set skip on lo scrub in rdr pass on bnx1 proto tcp from any to $MyPublicIP port 80 -> 10.0.0.2 block in log pass out pass in on bnx1 proto tcp from any to 10.0.0.2 port 80 flags S/SA synproxy state I didn't touch routes. Is there another way than using a set of rdr rules? Did I miss some man page?
Re: routing problem
I have tried doing a route-to rule but it makes no difference, I set it
up like this:
pass in quick on $ext_if route-to { ( $int_if (IP of host in DMZ ) }
from any to (IP of host in DMZ)
But my router still does not pass the packets onto the host in the DMZ,
I haven't tried a reply-to rule but I would have thought that the
route-to rule should tell the router to pass all packets with the
destination (IP of host in DMZ) on to (IP of host in DMZ).
For example even when this route-to rule is active and I try to ping a
host in the DMZ from the outside net, it gets no further than the
routers ext_if
It seems that any packet that comes into ext_if destined for any IP in
the DMZ does not get any further, even with route-to rule, which I don't
think is needed as all of the hosts are in the router's routing table
and are on the same network as the router.
Thanks,
Charlie
Daniel Anderson wrote:
Instead of giving you the obligatory "man pf.conf" reply, I will do one better
and reference an old reply I posed to the list with a sample pf.conf where
someone asked basically the same thing. I omitted the part that matters in
this example conf, but explain what you need to insert to get it to fly.
http://marc.info/?l=openbsd-misc&m=120665186412690&w=2
It all can be found under the man page on searching for reply-to or route-to.
This worked for me, so if anybody has got a more elegant means of doing it
they should post.
-
On Monday 20 October 2008 04:20:15 am Charlie Clark wrote:
Hi,
I am trying to setup an openbsd router but are having a big problem
getting it to work.
Here is the scenario:
The router has 3 public IP's, with 2 internet connections and sits just
outside a DMZ. Behind the router there are a number of hosts with public
IP's (DMZ).
All of the interfaces on the router are on different subnets.
Let's say that the 3 interfaces are:
int_if = the interface which is directly connected to the DMZ
ext_if = the first internet connection (NOTE this ISP is the ISP which
allocated the IP's in the DMZ so there is no natting done on this
interface) ext2_if = the second internet connection (NOTE there is
natting on this interface so everything works fine here)
I have setup aproxyd to answer arp requests on ext_if for all of the
IP's in the DMZ using the layout:
proxy (IP) (MAC of ext_if)
If I ping any IP on the net from a host in the DMZ and do a tcpdump on
the router at the same time, I can see the packet coming in int_if, then
going out ext_if, then the reply coming back in ext_if but then
disappearing. It doesn't seem to be passing the packets, destined for
the hosts in the DMZ, on to them.
Is there something I am missing here?
The filter rules look fine and nothing is being blocked
I would appreciate any help.
Thanks,
--
Charlie Clark
Network Engineer
Lemon Computing Ltd
Unit 9
26-28 Priests Bridge
London
SW14 8TA
UK
Tel: +44 208 878 2138
Fax: +44 208 878 2163
Email: [EMAIL PROTECTED]
Site: http://www.lemon-computing.com/
Lemon Computing is a limited company registered in England & Wales under
Company No. 03697052
Re: routing problem
Instead of giving you the obligatory "man pf.conf" reply, I will do one better and reference an old reply I posed to the list with a sample pf.conf where someone asked basically the same thing. I omitted the part that matters in this example conf, but explain what you need to insert to get it to fly. http://marc.info/?l=openbsd-misc&m=120665186412690&w=2 It all can be found under the man page on searching for reply-to or route-to. This worked for me, so if anybody has got a more elegant means of doing it they should post. - On Monday 20 October 2008 04:20:15 am Charlie Clark wrote: > Hi, > > I am trying to setup an openbsd router but are having a big problem > getting it to work. > Here is the scenario: > > The router has 3 public IP's, with 2 internet connections and sits just > outside a DMZ. Behind the router there are a number of hosts with public > IP's (DMZ). > All of the interfaces on the router are on different subnets. > Let's say that the 3 interfaces are: > > int_if = the interface which is directly connected to the DMZ > ext_if = the first internet connection (NOTE this ISP is the ISP which > allocated the IP's in the DMZ so there is no natting done on this > interface) ext2_if = the second internet connection (NOTE there is > natting on this interface so everything works fine here) > > I have setup aproxyd to answer arp requests on ext_if for all of the > IP's in the DMZ using the layout: > > proxy (IP) (MAC of ext_if) > > If I ping any IP on the net from a host in the DMZ and do a tcpdump on > the router at the same time, I can see the packet coming in int_if, then > going out ext_if, then the reply coming back in ext_if but then > disappearing. It doesn't seem to be passing the packets, destined for > the hosts in the DMZ, on to them. > > Is there something I am missing here? > The filter rules look fine and nothing is being blocked > > I would appreciate any help. > > Thanks,
routing problem
Hi, I am trying to setup an openbsd router but are having a big problem getting it to work. Here is the scenario: The router has 3 public IP's, with 2 internet connections and sits just outside a DMZ. Behind the router there are a number of hosts with public IP's (DMZ). All of the interfaces on the router are on different subnets. Let's say that the 3 interfaces are: int_if = the interface which is directly connected to the DMZ ext_if = the first internet connection (NOTE this ISP is the ISP which allocated the IP's in the DMZ so there is no natting done on this interface) ext2_if = the second internet connection (NOTE there is natting on this interface so everything works fine here) I have setup aproxyd to answer arp requests on ext_if for all of the IP's in the DMZ using the layout: proxy (IP) (MAC of ext_if) If I ping any IP on the net from a host in the DMZ and do a tcpdump on the router at the same time, I can see the packet coming in int_if, then going out ext_if, then the reply coming back in ext_if but then disappearing. It doesn't seem to be passing the packets, destined for the hosts in the DMZ, on to them. Is there something I am missing here? The filter rules look fine and nothing is being blocked I would appreciate any help. Thanks, -- Charlie Clark Network Engineer Lemon Computing Ltd Unit 9 26-28 Priests Bridge London SW14 8TA UK Tel: +44 208 878 2138 Fax: +44 208 878 2163 Email: [EMAIL PROTECTED] Site: http://www.lemon-computing.com/ Lemon Computing is a limited company registered in England & Wales under Company No. 03697052
VPN routing problem
Hi,
I have a VPN running that roughly looks like this:
LOCAL REMOTE
-
10.0.0.0/16 \ / mobile users
10.1.0.0/16 +- gateway - Internet -+- other users
10.6.0.0/16/\ subsidiary
Please assume that the gateway has the IP number 1.2.3.4. The VPN has a
hub-and-spoke topology, generally speaking.
The central gateway runs OpenBSD 4.3, the gateway at the subsidiary
site runs OpenBSD 4.2. I've configured everything using
isakmpd.conf+isakmpd.policy, and didn't yet figure out a way to move to
ipsec.conf, with my mix of certificates, shared secrets, fixed and
variable IP numbers, distinctive encryption algorithms, etc.
The mobile users are configured via IKE to get one IP address out of
10.3.0.0, with a default route through the gateway on the other side.
The other users get various IP addresses assigned, or provide their own
networks, and the subsidiary has 10.4.0.0/16.
I attach one network per location, so, for the connection with the
subsidiary, routing looks like this, when saying "netstat -rnf encap":
Source Destination SA...
10.0.0.0/15 10.4.0.0/16 1.2.3.4 and
10.4.0.0/16 10.0.0.0/15 1.2.3.4
Routing for mobile clients looks like this:
10.3.1.1 default 1.2.3.4and
default10.3.1.1 1.2.3.4
(one pair per client)
Everything worked very well so far...
The problem:
I'd like to establish reachability between 10.4.0.0/16 and 10.6.0.0/16.
So I thought I'd configure the subsidiary to have a default route to
the VPN in the same way that I announce a default route to the mobile
clients. I use the following stanza for this purpose:
[default-route]
ID-type=IPV4_ADDR_SUBNET
Network=0.0.0.0
Netmask=0.0.0.0
On the gateways, I switched the Phase2 IDs from
[east]
ID-type=IPV4_ADDR_SUBNET
Network=10.0.0.0
Netmask=255.254.0.0
to 'default-route' ('east' = central site).
But while doing so enables connectivity from the subsidiary to all
other nets (as could be confirmed using 'ping'), most applications
between the subsidiary and the central site, even in 10.0.0.0/15, break
horribly, and in unforseeable ways. Eg. telnet sessions breaking
half-way through, or other applications working only partially.
Reverting the change to only route to one network immediately "fixed"
the problem, sans the missing route to 10.6.0.0/16.
While debugging, I saw weird things like the gateway on the remote side
sending bogus (!) fragmentation messages for MTUs much smaller than the
default MTUs I've configured, to clients at the remote side, which
should have stayed in the remote network, over the VPN to the central
network, or clients in the remote network suddenly sending floods of
RST packets, where I couldn't discover the reason why they were sent,
for otherwise running applications.
The question:
How can I enable routing to discontiguous networks over VPN, and/or
what can I do to debug this problem further?
Kind regards,
--Toni++
Re: Difficult routing problem
Thomas Schoeller wrote: this will not work. ipsec will not encap packets that not belong to a flow. you need a second ipsec flow like on GW B: ike esp from LAN_B/24 to vendor/18 peer OPENBSD_A_External and on GW A: ike esp from VENDOR/18 to LAN_B/24 peer OPENBSD_B_External and then a route on GW A to the vendor network. i think this will do the trick. thomas Thanks, this worked great, just not sure why I didn't look at the ipsec flows for the solution. Layne Evans
Re: Difficult routing problem
On Sat, Oct 06, 2007 at 10:37:12AM -0400, Dave Anderson wrote: > On Sat, 6 Oct 2007, Layne Evans wrote: > > >Hello all, > > > > > >vendor -->vendor router<-- Internal LAN Location A -->OBSD GW A<-- Internet > > VPN Between > >Internet -->OBSD GW B<-- Internal LAN Location B > > > >Some info: (these are representative IPs) > >Vendor's IP block that need to go over their T1: 207.12.0.0/18 > >Internal LAN A: 10.74.10.0/24 > >Vendor router Internal LAN IP: 10.74.10.245 > >OpenBSD A Internal IP: 10.74.10.254 > >OpenBSD A External IP: a.b.c.d > >OpenBSD B Internal IP: 10.76.10.254 > >OpenBSD B External IP: w.x.y.z > > > >Any pointers will sure be appreciated. > > Maybe I'm missing something, but (given that everything else is working > and assuming that the systems on LAN B have a default route directed to > GW B) wouldn't a static route on GW B for 207.12.0.0/18 pointing to > 10.74.10.245 do the job? > this will not work. ipsec will not encap packets that not belong to a flow. you need a second ipsec flow like on GW B: ike esp from LAN_B/24 to vendor/18 peer OPENBSD_A_External and on GW A: ike esp from VENDOR/18 to LAN_B/24 peer OPENBSD_B_External and then a route on GW A to the vendor network. i think this will do the trick. thomas
Re: Difficult routing problem
On Sat, 6 Oct 2007, Layne Evans wrote: >Hello all, > >I am having some trouble with a routing situation that is difficult for >me to explain, so if you need more info let me know. > >vendor -->vendor router<-- Internal LAN Location A -->OBSD GW A<-- Internet > VPN Between >Internet -->OBSD GW B<-- Internal LAN Location B > > From the above I will try and describe the situation. A vendor has a >private T1 that terminates through NAT to the customers Internal LAN at >location A, the IP addresses that this vendor is using are part of there >public IP space but they are not routable over the Internet just through >the T1. I have a OpenBSD box at that location that provides internet >access and routes the block of IPs belonging to the vendor to the >vendor's router. > >There is a VPN between the OpenBSD boxes at both locations which is >performing fine and I can contact both internal LANs from the other. > >The problem that I have not been able to solve is that the workstations >at location B need to get to the vendor's router at location A using the >public IPs of the vendor. I have tried using route-to in pf and some >ideas I had in the routing table, but so far nothing has routed the >packets over the VPN. I am sure I am missing something basic, but so far >I have not been able to see it. > >Some info: (these are representative IPs) >Vendor's IP block that need to go over their T1: 207.12.0.0/18 >Internal LAN A: 10.74.10.0/24 >Vendor router Internal LAN IP: 10.74.10.245 >OpenBSD A Internal IP: 10.74.10.254 >OpenBSD A External IP: a.b.c.d >OpenBSD B Internal IP: 10.76.10.254 >OpenBSD B External IP: w.x.y.z > >Any pointers will sure be appreciated. Maybe I'm missing something, but (given that everything else is working and assuming that the systems on LAN B have a default route directed to GW B) wouldn't a static route on GW B for 207.12.0.0/18 pointing to 10.74.10.245 do the job? Dave -- Dave Anderson <[EMAIL PROTECTED]>
Difficult routing problem
Hello all, I am having some trouble with a routing situation that is difficult for me to explain, so if you need more info let me know. vendor -->vendor router<-- Internal LAN Location A -->OBSD GW A<-- Internet VPN Between Internet -->OBSD GW B<-- Internal LAN Location B From the above I will try and describe the situation. A vendor has a private T1 that terminates through NAT to the customers Internal LAN at location A, the IP addresses that this vendor is using are part of there public IP space but they are not routable over the Internet just through the T1. I have a OpenBSD box at that location that provides internet access and routes the block of IPs belonging to the vendor to the vendor's router. There is a VPN between the OpenBSD boxes at both locations which is performing fine and I can contact both internal LANs from the other. The problem that I have not been able to solve is that the workstations at location B need to get to the vendor's router at location A using the public IPs of the vendor. I have tried using route-to in pf and some ideas I had in the routing table, but so far nothing has routed the packets over the VPN. I am sure I am missing something basic, but so far I have not been able to see it. Some info: (these are representative IPs) Vendor's IP block that need to go over their T1: 207.12.0.0/18 Internal LAN A: 10.74.10.0/24 Vendor router Internal LAN IP: 10.74.10.245 OpenBSD A Internal IP: 10.74.10.254 OpenBSD A External IP: a.b.c.d OpenBSD B Internal IP: 10.76.10.254 OpenBSD B External IP: w.x.y.z Any pointers will sure be appreciated. Thanks Layne Evans
Re: nat or routing problem? SOLVED
Rod.. Whitworth wrote: > On Sat, 09 Dec 2006 14:34:04 +0100, Mitja wrote: > >> Mikael Fridh wrote: # pfctl -s all TRANSLATION RULES: nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 >>> If bge0 is your external interface that nat line now looks correct. >>> If your internal hosts on the 192.168.1.0/24 net have default gateway >>> 192.168.1.1 it should be nating properly. >> Yes and it is nating, but I am trying to set my source IP to >> 193.189.180.193 (em1). >> > Translating a bit from what I use should get you there: > > lan_ip="192.168.1.0/24" > ext_if="bge0" > fw_global-ip="193.189.180.193" > nat on $ext_if inet from $lan_ip to any -> $fw_global_ip > > I discovered this by (1) needing it, and (2) reading man 5 pf.conf and > checking the BNF grammar near the end, and (3) trying it. > > It saved me from half-bridging (messy) or renting a /32 (waste of $$). > > Without the quality of OpenBSD docs it may never have happened. Actually it works. Thank you! Regards, Mitja
Re: nat or routing problem?
On Sat, 09 Dec 2006 14:34:04 +0100, Mitja wrote: >Mikael Fridh wrote: >>> # pfctl -s all >>> TRANSLATION RULES: >>> nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) >>> rdr pass on em1 inet proto tcp from any to any port = 5900 -> >>> 192.168.1.111 port 5900 >> >> If bge0 is your external interface that nat line now looks correct. >> If your internal hosts on the 192.168.1.0/24 net have default gateway >> 192.168.1.1 it should be nating properly. > >Yes and it is nating, but I am trying to set my source IP to >193.189.180.193 (em1). > Translating a bit from what I use should get you there: lan_ip="192.168.1.0/24" ext_if="bge0" fw_global-ip="193.189.180.193" nat on $ext_if inet from $lan_ip to any -> $fw_global_ip I discovered this by (1) needing it, and (2) reading man 5 pf.conf and checking the BNF grammar near the end, and (3) trying it. It saved me from half-bridging (messy) or renting a /32 (waste of $$). Without the quality of OpenBSD docs it may never have happened. >From the land "down under": Australia. Do we look from up over?
Re: nat or routing problem?
Let's try this. It works, but the source IP is from bge0 my external interface (193.77.12.154). Then use address from em1 in nat rule for bge0. nat on bge0 inet from 192.168.1.0/24 to any -> (em1:0) No one said that translated source address must be the same as the address of nat external (outside) interface. Pozdrav, Aleksandar
Re: nat or routing problem?
Joel Goguen wrote: > On Fri, 08 Dec 2006 17:01:10 +0100, Mitja <[EMAIL PROTECTED]> wrote: >> Joel Goguen wrote: >>> On Fri, 08 Dec 2006 15:16:50 +0100, Mitja <[EMAIL PROTECTED]> wrote: >>> [snip] # pfctl -s all TRANSLATION RULES: nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) >>> If em1 is only serving the one IP address, try changing em1:0 to em1 and >> see if that works. >> >> Checked that option. It is the same...not working. > Upon closer review, I realize that I'm an idiot for even suggesting it :) > > You have a route that goes from your internal LAN (192.168.1.0/24) to em1 > (193.189.180.193). > You have another route that goes from 192.168.1.0/24 to your closest ISP > interface (193.77.12.154). Correct. > When you set up NAT from LAN to em1 and then ping an address that the routing > table says is > accessible from bge0, you skip NAT since you're not going out on em1. You're > going out on bge0, > which means that no translation is done. I'm not sure if it's possible to > ping from LAN and have Correct again. This is the point of the problem. It is actually possible to set NAT or remove a route from LAN to bge0? > your source IP be that of em1, but I think you can just add a second NAT rule > to allow NAT on bge0. > Someone beat me with a cluestick if I'm wrong :) So you'd end up with your > NAT section being: > nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) > nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) Actually natting from bge0 works so I think it will also work your idea, but the source IP will not be that from em1. > Again, I don't know if that would actually work, but that's the only other > idea I have now. Let's try this. It works, but the source IP is from bge0 my external interface (193.77.12.154). Regards, Mitja
Re: nat or routing problem?
Mikael Fridh wrote: >> # pfctl -s all >> TRANSLATION RULES: >> nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) >> rdr pass on em1 inet proto tcp from any to any port = 5900 -> >> 192.168.1.111 port 5900 > > If bge0 is your external interface that nat line now looks correct. > If your internal hosts on the 192.168.1.0/24 net have default gateway > 192.168.1.1 it should be nating properly. Yes and it is nating, but I am trying to set my source IP to 193.189.180.193 (em1). > Sounds like you want traffic to traverse: > 192.168.1.0/24 -> 192.168.1.1 -> 193.189.180.193 -> 193.77.12.154 -> 0/0 > I don't yet fully get what you're trying to accomplish. You got it right. That's what I am trying to accomplish: em0 em1 bge0 192.168.1.0/24 -> 192.168.1.1 -> 193.189.180.193 -> 193.77.12.154 -> 0/0 >> # tcpdump -i bge0 icmp >> tcpdump: listening on bge0, link-type EN10MB >> 14:49:16.377482 192.168.1.95 > 209.85.129.147: icmp: echo request >> 14:49:17.387437 192.168.1.95 > 209.85.129.147: icmp: echo request >> 14:49:18.397398 192.168.1.95 > 209.85.129.147: icmp: echo request >> >> icmp packets are going out, but it looks like NAT is not working (it >> should change my source IP address). > > That's because now you are dumping traffic on the "internal" interface > where the packets hasn't traversed the NAT yet. > The nat rule you made above has the internal interface where it should > have the external: >> nat on em1:0 from int_net to -> em1:0. bge0 is my external interface (it routes to 0/0). em1 is a network with a range of pubblic IPs. I am trying to use one of those IPs, to NAT traffic from. > # This is a proper simple nat example (that works): > ext_if="rl0" # (or whatever is your external interface) > nat on $ext_if inet from ! ($ext_if) -> ($ext_if:0) This means NAT from all interfaces but not from the external one. It is correct to use this statement? # pfctl -s all TRANSLATION RULES: nat on em1 inet from ! (em1) to any -> (em1:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 I tested with suggested configuration. tcpdump on my external (bge0) interface shows gateway private IP (192.168.1.1). So the packets did not traverse NAT yet. # ping -I 192.168.1.1 72.14.221.104 # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:29:50.077139 192.168.1.1 > 72.14.221.147: icmp: echo request 14:29:51.086365 192.168.1.1 > 72.14.221.147: icmp: echo request 14:29:52.096350 192.168.1.1 > 72.14.221.147: icmp: echo request Other ideas? Regards, Mitja
Re: nat or routing problem?
Mitja wrote: Mitja wrote: Andreas Bihlmaier wrote: On Thu, Dec 07, 2006 at 11:27:11PM +0100, Mitja wrote: Hello, I am trying to configure nat from internal network 192.168.1.0/24 to external nat gateway address 193.189.180.193. The problem is that packets are not passing from nat gateway to the interface 193.77.12.154 to the internet. ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1 | 193.189.180.193 (em1) | /27 network More testing: I changed my pf.conf to: # pfctl -s all TRANSLATION RULES: nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 If bge0 is your external interface that nat line now looks correct. If your internal hosts on the 192.168.1.0/24 net have default gateway 192.168.1.1 it should be nating properly. Sounds like you want traffic to traverse: 192.168.1.0/24 -> 192.168.1.1 -> 193.189.180.193 -> 193.77.12.154 -> 0/0 I don't yet fully get what you're trying to accomplish. # pfctl -s all TRANSLATION RULES: nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 FILTER RULES: pass in all keep state pass out all keep state No queue in use The same test, with tcpdump on the last interface (bge0;193.77.12.154). # ping -I 192.168.1.95 209.85.129.147 PING 209.85.129.147 (209.85.129.147): 56 data bytes --- 209.85.129.147 ping statistics --- 15 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:49:16.377482 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:17.387437 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:18.397398 192.168.1.95 > 209.85.129.147: icmp: echo request icmp packets are going out, but it looks like NAT is not working (it should change my source IP address). That's because now you are dumping traffic on the "internal" interface where the packets hasn't traversed the NAT yet. The nat rule you made above has the internal interface where it should have the external: nat on em1:0 from int_net to -> em1:0. # This is a proper simple nat example (that works): ext_if="rl0" # (or whatever is your external interface) nat on $ext_if inet from ! ($ext_if) -> ($ext_if:0) -- Fridh
Re: nat or routing problem?
Mitja wrote: Mitja wrote: Andreas Bihlmaier wrote: On Thu, Dec 07, 2006 at 11:27:11PM +0100, Mitja wrote: Hello, I am trying to configure nat from internal network 192.168.1.0/24 to external nat gateway address 193.189.180.193. The problem is that packets are not passing from nat gateway to the interface 193.77.12.154 to the internet. ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1 | 193.189.180.193 (em1) | /27 network More testing: I changed my pf.conf to: # pfctl -s all TRANSLATION RULES: nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 FILTER RULES: pass in all keep state pass out all keep state No queue in use Now I am doing translation from 192.168.1.0/24 to bge0 (193.77.12.154), the closest interface to my ISP. Test: # ping -I 192.168.1.95 209.85.129.147 PING 209.85.129.147 (209.85.129.147): 56 data bytes 64 bytes from 209.85.129.147: icmp_seq=0 ttl=242 time=45.439 ms 64 bytes from 209.85.129.147: icmp_seq=1 ttl=242 time=45.307 ms --- 209.85.129.147 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 45.307/45.373/45.439/0.066 ms # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:46:10.614558 193.77.12.154 > 209.85.129.147: icmp: echo request 14:46:10.659932 209.85.129.147 > 193.77.12.154: icmp: echo reply 14:46:11.624513 193.77.12.154 > 209.85.129.147: icmp: echo request 14:46:11.669838 209.85.129.147 > 193.77.12.154: icmp: echo reply It looks like NAT is working. The same test with changed configuration in pf.conf to: # pfctl -s all TRANSLATION RULES: nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 FILTER RULES: pass in all keep state pass out all keep state No queue in use The same test, with tcpdump on the last interface (bge0;193.77.12.154). # ping -I 192.168.1.95 209.85.129.147 PING 209.85.129.147 (209.85.129.147): 56 data bytes --- 209.85.129.147 ping statistics --- 15 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:49:16.377482 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:17.387437 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:18.397398 192.168.1.95 > 209.85.129.147: icmp: echo request icmp packets are going out, but it looks like NAT is not working (it should change my source IP address). Maybe, you should try somthing like this. nat on bge0 inet from 192.168.1.0/24 to any -> (em1:0) nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) rdr ... I might work. Pozdrav, Aleksandar
Re: nat or routing problem?
Joel Goguen wrote: > On Fri, 08 Dec 2006 15:16:50 +0100, Mitja <[EMAIL PROTECTED]> wrote: > [snip] >> # pfctl -s all >> TRANSLATION RULES: >> nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) > If em1 is only serving the one IP address, try changing em1:0 to em1 and see > if that works. Checked that option. It is the same...not working. Regards, Mitja
Re: nat or routing problem?
On Fri, 08 Dec 2006 15:16:50 +0100, Mitja <[EMAIL PROTECTED]> wrote: [snip] > # pfctl -s all > TRANSLATION RULES: > nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) If em1 is only serving the one IP address, try changing em1:0 to em1 and see if that works. -- Joel Goguen http://iapetus.dyndns.org/
Re: nat or routing problem?
Mitja wrote: > Andreas Bihlmaier wrote: >> On Thu, Dec 07, 2006 at 11:27:11PM +0100, Mitja wrote: >>> Hello, >>> >>> I am trying to configure nat from internal network 192.168.1.0/24 to >>> external nat gateway address 193.189.180.193. The problem is that >>> packets are not passing from nat gateway to the interface 193.77.12.154 >>> to the internet. >>> >>> ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1 >>>| >>> 193.189.180.193 (em1) >>>| >>>/27 network More testing: I changed my pf.conf to: # pfctl -s all TRANSLATION RULES: nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 FILTER RULES: pass in all keep state pass out all keep state No queue in use Now I am doing translation from 192.168.1.0/24 to bge0 (193.77.12.154), the closest interface to my ISP. Test: # ping -I 192.168.1.95 209.85.129.147 PING 209.85.129.147 (209.85.129.147): 56 data bytes 64 bytes from 209.85.129.147: icmp_seq=0 ttl=242 time=45.439 ms 64 bytes from 209.85.129.147: icmp_seq=1 ttl=242 time=45.307 ms --- 209.85.129.147 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 45.307/45.373/45.439/0.066 ms # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:46:10.614558 193.77.12.154 > 209.85.129.147: icmp: echo request 14:46:10.659932 209.85.129.147 > 193.77.12.154: icmp: echo reply 14:46:11.624513 193.77.12.154 > 209.85.129.147: icmp: echo request 14:46:11.669838 209.85.129.147 > 193.77.12.154: icmp: echo reply It looks like NAT is working. The same test with changed configuration in pf.conf to: # pfctl -s all TRANSLATION RULES: nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 FILTER RULES: pass in all keep state pass out all keep state No queue in use The same test, with tcpdump on the last interface (bge0;193.77.12.154). # ping -I 192.168.1.95 209.85.129.147 PING 209.85.129.147 (209.85.129.147): 56 data bytes --- 209.85.129.147 ping statistics --- 15 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:49:16.377482 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:17.387437 192.168.1.95 > 209.85.129.147: icmp: echo request 14:49:18.397398 192.168.1.95 > 209.85.129.147: icmp: echo request icmp packets are going out, but it looks like NAT is not working (it should change my source IP address). I checked with google, http://www.openbsd.org/faq/pf/nat.html, http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&arch=&apropos=0&manpath=OpenBSD+4.0 and did not found anything usefull. I'm stuck. Any ideas? Regards, Mitja
Re: nat or routing problem?
Andreas Bihlmaier wrote: > On Thu, Dec 07, 2006 at 11:27:11PM +0100, Mitja wrote: >> Hello, >> >> I am trying to configure nat from internal network 192.168.1.0/24 to >> external nat gateway address 193.189.180.193. The problem is that >> packets are not passing from nat gateway to the interface 193.77.12.154 >> to the internet. >> >> ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1 >>| >> 193.189.180.193 (em1) >>| >>/27 network >> >> All hosts on 193.189.180.192/27 are routed correctly through >> 193.77.12.154 to internet. My pf.conf is practically empty: >> >> # pfctl -s all >> TRANSLATION RULES: >> nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) >> rdr pass on em1 inet proto tcp from any to any port = 5900 -> >> 192.168.1.111 port 5900 >> >> FILTER RULES: >> pass in all keep state >> pass out all keep state >> No queue in use >> >> What I am doing wrong? Any suggestions? > > #grep forwarding /etc/sysctl.conf Enabled... net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4 packets #net.inet.ip.mforwarding=1 # 1=Permit forwarding (routing) of IPv4 multicast packets #net.inet6.ip6.forwarding=1 # 1=Permit forwarding (routing) of IPv6 packets #net.inet6.ip6.accept_rtadv=1 # 1=Permit IPv6 autoconf (forwarding must be 0) For additional info: # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default193.77.12.153 UGS 963486 - bge0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 1 92 33224 lo0 172.16.15.4/30 link#4 UC 10 - bge1 172.16.15.500:05:85:86:84:7e UHLc10 - bge1 172.16.16.6172.16.15.5UGHS218739 - bge1 192.168.1/24 link#1 UC 20 - em0 192.168.1.20 00:0f:1f:02:44:1f UHLc0 10 - em0 192.168.1.111 00:60:97:82:73:ce UHLc00 - em0 193.77.12.152/30 link#3 UC 10 - bge0 193.77.12.153 00:05:85:86:84:7e UHLc10 - bge0 193.189.180.192/27 link#2 UC 50 - em1 224/4 127.0.0.1 URS 00 33224 lo0 Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.1.1/24 0 192.168.1/24 0 0 172.16.16.6/esp/use/in 192.168.1/24 0 10.1.1/24 0 0 172.16.16.6/esp/require/out 172.16.16.6/32 0 172.16.15.6/32 0 0 172.16.16.6/esp/use/in 172.16.15.6/32 0 172.16.16.6/32 0 0 172.16.16.6/esp/require/out 193.189.180.128/27 0 default0 0 172.16.16.6/esp/use/in default0 193.189.180.128/27 0 0 172.16.16.6/esp/require/out Regards, Mitja
Re: nat or routing problem?
On Thu, Dec 07, 2006 at 11:27:11PM +0100, Mitja wrote: > Hello, > > I am trying to configure nat from internal network 192.168.1.0/24 to > external nat gateway address 193.189.180.193. The problem is that > packets are not passing from nat gateway to the interface 193.77.12.154 > to the internet. > > ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1 >| > 193.189.180.193 (em1) >| >/27 network > > All hosts on 193.189.180.192/27 are routed correctly through > 193.77.12.154 to internet. My pf.conf is practically empty: > > # pfctl -s all > TRANSLATION RULES: > nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) > rdr pass on em1 inet proto tcp from any to any port = 5900 -> > 192.168.1.111 port 5900 > > FILTER RULES: > pass in all keep state > pass out all keep state > No queue in use > > What I am doing wrong? Any suggestions? #grep forwarding /etc/sysctl.conf > DMESG: Regards, ahb
nat or routing problem?
Hello,
I am trying to configure nat from internal network 192.168.1.0/24 to
external nat gateway address 193.189.180.193. The problem is that
packets are not passing from nat gateway to the interface 193.77.12.154
to the internet.
ISP <-> 193.77.12.154 -- hostA -- 192.168.1.1
|
193.189.180.193 (em1)
|
/27 network
All hosts on 193.189.180.192/27 are routed correctly through
193.77.12.154 to internet. My pf.conf is practically empty:
# pfctl -s all
TRANSLATION RULES:
nat on em1 inet from 192.168.1.0/24 to any -> (em1:0)
rdr pass on em1 inet proto tcp from any to any port = 5900 ->
192.168.1.111 port 5900
FILTER RULES:
pass in all keep state
pass out all keep state
No queue in use
What I am doing wrong? Any suggestions?
DMESG:
==
OpenBSD 4.0 (fw) #0: Wed Nov 8 13:12:58 CET 2006
[EMAIL PROTECTED]:/usr/src/fw
cpu0: AMD Opteron(tm) Processor 146 ("AuthenticAMD" 686-class, 1024KB L2
cache) 2 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3
real mem = 1073246208 (1048092K)
avail mem = 970592256 (947844K)
using 4256 buffers containing 53764096 bytes (52504K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 07/15/06, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.4 @ 0xf8e00 (50 entries)
bios0: Supermicro H8SSL
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4f50/160 (8 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1166 product 0x0205
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x2000! 0xca000/0x1600
0xcb800/0x1600 0xcd000/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
ppb0 at pci0 dev 1 function 0 "ServerWorks HT-1000 PCI" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 13 function 0 "ServerWorks HT-1000 PCIX" rev 0xb2
pci2 at ppb1 bus 2
em0 at pci2 dev 1 function 0 "Intel PRO/1000MT (82546GB)" rev 0x03: irq
9, address 00:04:23:d0:93:60
em1 at pci2 dev 1 function 1 "Intel PRO/1000MT (82546GB)" rev 0x03: irq
5, address 00:04:23:d0:93:61
bge0 at pci2 dev 3 function 0 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 7, address 00:30:48:5b:0a:88
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci2 dev 3 function 1 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 9, address 00:30:48:5b:0a:89
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
pciide0 at pci1 dev 14 function 0 "ServerWorks SATA" rev 0x00: DMA
pciide0: using irq 11 for native-PCI interrupt
pciide0: port 0: device present, speed: 1.5Gb/s
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: port 1: device present, speed: 1.5Gb/s
wd1 at pciide0 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: port 2: PHY offline
pciide0: port 3: PHY offline
pciide1 at pci1 dev 14 function 1 "ServerWorks SATA" rev 0x00
piixpm0 at pci0 dev 2 function 0 "ServerWorks HT-1000" rev 0x00: polling
iic0 at piixpm0
admcts0 at iic0 addr 0x2c
pciide2 at pci0 dev 2 function 1 "ServerWorks HT-1000 IDE" rev 0x00: DMA
atapiscsi0 at pciide2 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
removable
cd0(pciide2:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 0
pcib0 at pci0 dev 2 function 2 "ServerWorks HT-1000 LPC" rev 0x00
ohci0 at pci0 dev 3 function 0 "ServerWorks HT-1000 USB" rev 0x01: irq
10, version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci0 dev 3 function 1 "ServerWorks HT-1000 USB" rev 0x01: irq
10, version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 3 function 2 "ServerWorks HT-1000 USB" rev 0x01: irq 10
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: ServerWorks EHCI root hub, rev 2.00/1.00, addr 1
uhub2: 4 ports with 4 removable, self powered
vga1 at pci0 dev 5 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux s
Re: IPSec routing problem when using UDP
Yes, my bad. I didn't include any other information because I didn't think it could be version specific. We are using OpenBSD 3.8, and OpenVPN 2.0.6 (from packages). You are right about IPSec not routing. What I meant is how the configured flows are being chosen/matched so that the OS routes the packets through the enc interface or the dmz interface. We are not using carp on that machine. About the ARP issue, we are not connecting between locally attached hosts, so I'm not sure of what you mean, or how it would affect us. When you say toss, you mean discard? I _can_ see the udp reply packet generated by OpenVPN going through the enc0 using tcpdump when connecting from the Internet. There's also the issue of why flushing and reloading the ipsec tunnels/flows solves the problem temporarily. One thing I forgot to mention that may be part of this problem: when we connect to this machine from the office on the other end, the packets don't go through an ipsec tunnel (ie, no flow is used), but when the box running OpenVPN replies, they _do_ get back trough a flow. The first part is also true for someone connecting from the Internet, but the replying packets should get routed trough the dmz interface going to the Internet, not the enc interface. This does work for some time, until, for some reason, they begin to appear in the enc interface. Let me know if this clarifies my first message and if you need more info. Thanks, Martmn. David Bryan wrote: > You may want to include some more information, like what version of > OpenBSD your running, and one version of OpenVPN your running. > One thing you must remember is that IPSec does not route, packets must > match an IPSec profile and are then that packet is wraped up in an > IPSec header and sent across to the remote end. > > If you can get to it with TCP, but not UDP you may have either an ARP > issue (EG: UDP tosses the packet, and does not try again, and > generally it does not get status messages) or a CARP/PF rule set issue. > > More info is needed before questions can be answered. > > Martmn Coco wrote: > >> Hello misc! >> >> We are experiencing what seems to be a routing problem when using ipsec >> flows and udp traffic. >> >> We are using OpenVPN for the employees to connect from the outside world >> to our network. It is configured to use UDP. At the same time, this box >> has an ipsec tunnel configured to talk between different offices in >> different countries. >> >> The problem seems to be that, at some point in time, all the udp packets >> coming from anywhere end up being routed through the enc0 interface, >> when some of them (the ones coming through the Internet and not from our >> other office) should be routed normally, without using any ipsec flow. >> This of course causes all OpenVPN connection attempts coming from the >> Internet to fail, as they will never receive an aswer from the server. >> >> This is not the first time we've encountered this behaviour. I've also >> seen this happening when using named together with ipsec tunnels. The >> very same thing would happen (ie, packets that should go to the Internet >> being routed via enc0). >> >> We have just realised that in both cases, OpenVPN and named, UDP might >> be in use. When the OpenVPN server begins to "misbehave", I can still >> connect via ssh from the Internet (thus discarding TCP issues). >> >> To solve this we have to flush the ipsec tunnels. This seems to solve >> the issue. >> >> The pf rules seem to be alright, keeping state for udp connections. The >> only thing that we may be doing wrong is the ipsec flow configuration, >> but why would it work for some time, to show the detailed behaviour only >> after a couple of hours? >> >> I'll appreciate your input, >> Martmn.
Re: IPSec routing problem when using UDP
You may want to include some more information, like what version of OpenBSD your running, and one version of OpenVPN your running. One thing you must remember is that IPSec does not route, packets must match an IPSec profile and are then that packet is wraped up in an IPSec header and sent across to the remote end. If you can get to it with TCP, but not UDP you may have either an ARP issue (EG: UDP tosses the packet, and does not try again, and generally it does not get status messages) or a CARP/PF rule set issue. More info is needed before questions can be answered. Martmn Coco wrote: Hello misc! We are experiencing what seems to be a routing problem when using ipsec flows and udp traffic. We are using OpenVPN for the employees to connect from the outside world to our network. It is configured to use UDP. At the same time, this box has an ipsec tunnel configured to talk between different offices in different countries. The problem seems to be that, at some point in time, all the udp packets coming from anywhere end up being routed through the enc0 interface, when some of them (the ones coming through the Internet and not from our other office) should be routed normally, without using any ipsec flow. This of course causes all OpenVPN connection attempts coming from the Internet to fail, as they will never receive an aswer from the server. This is not the first time we've encountered this behaviour. I've also seen this happening when using named together with ipsec tunnels. The very same thing would happen (ie, packets that should go to the Internet being routed via enc0). We have just realised that in both cases, OpenVPN and named, UDP might be in use. When the OpenVPN server begins to "misbehave", I can still connect via ssh from the Internet (thus discarding TCP issues). To solve this we have to flush the ipsec tunnels. This seems to solve the issue. The pf rules seem to be alright, keeping state for udp connections. The only thing that we may be doing wrong is the ipsec flow configuration, but why would it work for some time, to show the detailed behaviour only after a couple of hours? I'll appreciate your input, Martmn.
IPSec routing problem when using UDP
Hello misc! We are experiencing what seems to be a routing problem when using ipsec flows and udp traffic. We are using OpenVPN for the employees to connect from the outside world to our network. It is configured to use UDP. At the same time, this box has an ipsec tunnel configured to talk between different offices in different countries. The problem seems to be that, at some point in time, all the udp packets coming from anywhere end up being routed through the enc0 interface, when some of them (the ones coming through the Internet and not from our other office) should be routed normally, without using any ipsec flow. This of course causes all OpenVPN connection attempts coming from the Internet to fail, as they will never receive an aswer from the server. This is not the first time we've encountered this behaviour. I've also seen this happening when using named together with ipsec tunnels. The very same thing would happen (ie, packets that should go to the Internet being routed via enc0). We have just realised that in both cases, OpenVPN and named, UDP might be in use. When the OpenVPN server begins to "misbehave", I can still connect via ssh from the Internet (thus discarding TCP issues). To solve this we have to flush the ipsec tunnels. This seems to solve the issue. The pf rules seem to be alright, keeping state for udp connections. The only thing that we may be doing wrong is the ipsec flow configuration, but why would it work for some time, to show the detailed behaviour only after a couple of hours? I'll appreciate your input, Martmn.
Re: Routing problem?
Hey, Try a bridge. man brconfig(8) says: he brconfig utility retrieves kernel state of bridge interfaces and al- lows user control of these bridges. Bridge devices create a logical link between two or more Ethernet interfaces or encapsulation interfaces (see gif(4)), which will selectively forward frames from each interface on the bridge to every other interface on the bridge. This can be used to iso- late traffic between sets of machines on the same segment and to provide a transparent filter for ip(4) datagrams. Which pretty much what you want to do (e,g. isolate traffic between the router and the DMZ). T he put its interface into promiscuous mode all see all traffic. THe DMZ keeps in own adddress. Take a look at BRCONFIG(8) Respectfully, Tony Sterrett [EMAIL PROTECTED] Consultant in Open Source Software, featuring OpenBSD and Linux. www.sterrett.net On Jan 22, 2006, at 10:07 AM, Jonas Lindskog wrote: > Hello, > > We are running Open BSD 3.8 as a firewall router. The router has > two internal networks to handle; a DMZ with "real" > ip adresses and a NAT network to which our workstations are > connected. The problem I have is that its not possible to > connect to the server on the DMZ (ip 38.87.5.122, netmask > 255.255.255.252) from the outside (but from the inside). > I guess that I somehow has to make the external interface listen to > the same adress as the server (they are on the same net), but if I add > an alias to the external interface it doesn't (of course) route > packages to the DMZ. How do I make OpenBSD route packages to the > server > (and the DMZ subnet)? > > Our ISP has given us a net that has the following data: > > Net segment: 38.87.5.112 /28 net address: 38.87.5.112 > gw address: 38.87.5.113 > firewall: 38.87.5.114 > free ip ip: 38.87.5.115-126 > broadcast address:38.87.5.127 > netmask: 255.255.255.240 > > the server has the following interfaces configured: > ### interfaces > #external interface > inet 38.87.5.114 255.255.255.240 NONE > > #internal interface > inet 192.168.97.254 255.255.255.0 NONE > > # dmz > inet 38.87.5.121 255.255.255.252 NONE > > Thanks in advance > > Jonas
Re: Routing problem?
Jonas Lindskog wrote: > We are running Open BSD 3.8 as a firewall router. The router has two > internal networks to handle; a DMZ with "real" > ip adresses and a NAT network to which our workstations are connected. > The problem I have is that its not possible to > connect to the server on the DMZ (ip 38.87.5.122, netmask > 255.255.255.252) from the outside (but from the inside). > I guess that I somehow has to make the external interface listen to > the same adress as the server (they are on the same net), but if I add > an alias to the external interface it doesn't (of course) route > packages to the DMZ. How do I make OpenBSD route packages to the > server (and the DMZ subnet)? > > Our ISP has given us a net that has the following data: > > Net segment: 38.87.5.112 /28 > net address: 38.87.5.112 > gw address: 38.87.5.113 > firewall: 38.87.5.114 > free ip ip: 38.87.5.115-126 > broadcast address:38.87.5.127 > netmask: 255.255.255.240 > > the server has the following interfaces configured: > ### interfaces > #external interface > inet 38.87.5.114 255.255.255.240 NONE > > #internal interface > inet 192.168.97.254 255.255.255.0 NONE > > # dmz > inet 38.87.5.121 255.255.255.252 NONE This is not an OpenBSD issue--you might want to learn about IP routing. Either loose a bunch IPs and route the traffic properly, by putting 38.87.5.114/30 on your external interface and 38.87.5.121/29 on your DMZ interface, or use NAT for everything. There might be a better way to route this without loosing any IPs, but, if so, I haven't thought about it/done it before.
Re: Routing problem?
On Jan 22, 2006, at 1:07 PM, Jonas Lindskog wrote: Hello, We are running Open BSD 3.8 as a firewall router. The router has two internal networks to handle; a DMZ with "real" ip adresses and a NAT network to which our workstations are connected. The problem I have is that its not possible to connect to the server on the DMZ (ip 38.87.5.122, netmask 255.255.255.252) from the outside (but from the inside). I guess that I somehow has to make the external interface listen to the same adress as the server (they are on the same net), but if I add an alias to the external interface it doesn't (of course) route packages to the DMZ. How do I make OpenBSD route packages to the server (and the DMZ subnet)? http://www.openbsd.org/faq/pf/rdr.html#reflect -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Routing problem?
Hello, We are running Open BSD 3.8 as a firewall router. The router has two internal networks to handle; a DMZ with "real" ip adresses and a NAT network to which our workstations are connected. The problem I have is that its not possible to connect to the server on the DMZ (ip 38.87.5.122, netmask 255.255.255.252) from the outside (but from the inside). I guess that I somehow has to make the external interface listen to the same adress as the server (they are on the same net), but if I add an alias to the external interface it doesn't (of course) route packages to the DMZ. How do I make OpenBSD route packages to the server (and the DMZ subnet)? Our ISP has given us a net that has the following data: Net segment: 38.87.5.112 /28 net address: 38.87.5.112 gw address: 38.87.5.113 firewall: 38.87.5.114 free ip ip: 38.87.5.115-126 broadcast address:38.87.5.127 netmask: 255.255.255.240 the server has the following interfaces configured: ### interfaces #external interface inet 38.87.5.114 255.255.255.240 NONE #internal interface inet 192.168.97.254 255.255.255.0 NONE # dmz inet 38.87.5.121 255.255.255.252 NONE Thanks in advance Jonas
Re: Odd routing problem ?
On 12/16/05, Joachim Schipper <[EMAIL PROTECTED]> wrote: > > > Every attempt to access any host on the Internet gets to gwA > > int_wireless, but doesn't goes out on ext_if. gwB can't even ping gwA > > external address 1.2.3.2. > > I assume gwA and gwB can ping each other on the internal interface, at > least. Yes. That's correct. In fact, I can connect to gwB from the Internet. Anything coming from the Internet gets routed correctly. > > gwB's > > - > > gwB:24$ cat /etc/hostname.sis0 > >inet 10.10.10.250 > > 255.255.255.0 NONE > > inet alias 1.2.3.65 255.255.255.192 NONE > > gwB:25$ > > Okay, should work. I assume you've set gwA as default gateway? yes. 10.10.10.254 is the default gateway for gwB > > gwA's > > - > > gwA:511$ cat /etc/hostname.xl0 > > inet 10.10.10.254 255.255.255.0 NONE > > !/sbin/route add -net 1.2.3.64/26 10.10.10.250 > > Okay, should work, too. Wireless is a bitch, but I suppose everything > works, where the hardware is concerned. > > > gwA:512$ cat /etc/hostname.sis0 > > inet 1.2.3.2 255.255.255.192 NONE > > gwA:513$ > > Are you certain that gwA->sis0 should have that netmask? If it is indeed > internet-connected, it probably shouldn't. Yes. The other /26 block was designed to be in gwB's domain. > > gwA:514$ sysctl -a net.inet.ip.forwarding > > net.inet.ip.forwarding=1 > > > > Has anyone a clue ? > > Nothing definitive, but (unless the above solves it) I'd like to see the > routing tables. I'm not entirely certain where the default route goes, > in particular. gwB -- gwB:4$ netstat -rnf inet ; netstat -rnf encap Routing tables Internet: DestinationGatewayFlags Refs UseMtu Interface default10.10.10.254 UGS 8 247617 - sis0 10.10.10/24link#1 UC 10 - sis0 10.10.10.254 0:2:6f:3c:59:9cUHLc1 15 - sis0 10.101.2/24link#2 UC 40 - rl0 10.101.2.101 0:11:5b:6:9a:1fUHLc110752 - rl0 10.101.2.102 0:50:be:56:3f:d5 UHLc099043 - rl0 10.101.2.105 0:7:95:dd:ad:c5UHLc012737 - rl0 10.101.2.120 0:7:95:31:8e:b8UHLc428001 - rl0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 3 106 33224 lo0 1.2.3.64/26 link#1 UC 00 - sis0 1.2.3.65 127.0.0.1 UGHS00 33224 lo0 224/4 127.0.0.1 URS 00 33224 lo0 Routing tables Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.101.99/24 0 10.101.2/240 0 1.5.6130/50/use/in 10.101.2/240 10.101.99/24 0 0 1.5.6.130/50/require/out gwB:5$ gwA --- gwA:530$ netstat -rnf inet;netstat -rnf encap Routing tables Internet: DestinationGatewayFlags Refs UseMtu Interface default1.2.3.1 UGS 7 1598443 - sis0 10.10.10/24link#2 UC 10 - xl0 10.10.10.250 0:2:6f:3a:bc:c7UHLc3 95 - xl0 10.101.1/24link#3 UC 100 - vr0 10.101.1.5 0:40:33:aa:68:b0 UHLc0 2675 - vr0 10.101.1.110:d:87:1:a3:55 UHLc113323 - vr0 10.101.1.101 0:11:5b:12:59:72 UHLc0 4401 - vr0 10.101.1.102 0:30:21:a0:7c:16 UHLc0 3136 - vr0 10.101.1.105 0:e0:7d:b3:85:6e UHLc020417 - vr0 10.101.1.106 0:d0:9:f1:13:44UHLc015656 - vr0 10.101.1.120 0:a:e6:86:16:a7UHLc1 2212 - vr0 10.101.1.121 0:e0:4c:e1:e1:cd UHLc016732 - vr0 10.101.1.123 0:d:87:ce:f9:deUHLc020775 - vr0 10.101.1.254 0:8:54:32:b2:7fUHLc0 128 - lo0 10.101.2/2410.10.10.250 UGS 00 - xl0 10.101.5/24link#3 UC 40 - vr0 10.101.5.101 0:e0:7d:b2:ec:4c UHLc0 8005 - vr0 10.101.5.106 0:e:a6:7d:4a:f8UHLc0 1705 - vr0 10.101.5.107 0:0:e8:ec:94:bbUHLc1 8337 - vr0 10.101.5.120 0:e0:7d:73:55:cb UHLc0 3630 - vr0 10.101.5.254 127.0.0.1 UGHS00 33224 lo0 10.101.99.11.2.3.1 UGHD0 1594991 1444 sis0 10.101.99.80 1.2.3.1 UGHD0 1587957 1444 sis0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 2 152 33224 lo0 1.2.3.0/26 link#1 UC
Re: Odd routing problem ?
On 12/16/05, Bryan Irvine <[EMAIL PROTECTED]> wrote: > traceroute is your friend. I'm sure you've tried it, just didn't post > the results? It doesn't show any hop. Like ping, we only see packets coming into wireless interface of gwA, and they don't ever come out of it. -- Fernando M. Braga
Re: Odd routing problem ?
(reply inline, sorry) On Fri, Dec 16, 2005 at 01:34:38PM -0300, Fernando Braga wrote: > I'm facing an unusual problem with routing. I can access an internal > server (with real IP) thru an OpenBSD gateway (gwA). Everything works > when connection is initiated from the Internet. But gwB can't make its > way back to the Internet. > > Every attempt to access any host on the Internet gets to gwA > int_wireless, but doesn't goes out on ext_if. gwB can't even ping gwA > external address 1.2.3.2. I assume gwA and gwB can ping each other on the internal interface, at least. > gwA has 3 interfaces: sis0 (external), vr0 (internal), and xl0 (int_wireless). > gwB has 2 interfaces: sis0 (ext_wireless), and rl0 (internal). > > +---+ +-+ > | gwB |sis0<< RADIO BRIDGES >>xl0| gwA |sis0-<< INTERNET >> > +---+ +-+ > > gwB's > - > gwB:24$ cat /etc/hostname.sis0 >inet 10.10.10.250 > 255.255.255.0 NONE > inet alias 1.2.3.65 255.255.255.192 NONE > gwB:25$ Okay, should work. I assume you've set gwA as default gateway? > gwA's > - > gwA:511$ cat /etc/hostname.xl0 > inet 10.10.10.254 255.255.255.0 NONE > !/sbin/route add -net 1.2.3.64/26 10.10.10.250 Okay, should work, too. Wireless is a bitch, but I suppose everything works, where the hardware is concerned. > gwA:512$ cat /etc/hostname.sis0 > inet 1.2.3.2 255.255.255.192 NONE > gwA:513$ Are you certain that gwA->sis0 should have that netmask? If it is indeed internet-connected, it probably shouldn't. > gwA:514$ sysctl -a net.inet.ip.forwarding > net.inet.ip.forwarding=1 > > Has anyone a clue ? Nothing definitive, but (unless the above solves it) I'd like to see the routing tables. I'm not entirely certain where the default route goes, in particular. Joachim
Re: Odd routing problem ?
traceroute is your friend. I'm sure you've tried it, just didn't post the results? On 12/16/05, Fernando Braga <[EMAIL PROTECTED]> wrote: > Hi, > > I'm facing an unusual problem with routing. I can access an internal > server (with real IP) thru an OpenBSD gateway (gwA). Everything works > when connection is initiated from the Internet. But gwB can't make its > way back to the Internet. > > Every attempt to access any host on the Internet gets to gwA > int_wireless, but doesn't goes out on ext_if. gwB can't even ping gwA > external address 1.2.3.2. > > It makes no difference whether pf is enabled or not and, yes, > net.inet.ip.forward is enabled. > > They're connected thru wireless bridges. I'll try to represent the > network below: > > gwA has 3 interfaces: sis0 (external), vr0 (internal), and xl0 (int_wireless). > gwB has 2 interfaces: sis0 (ext_wireless), and rl0 (internal). > > +---+ +-+ > | gwB |sis0<< RADIO BRIDGES >>xl0| gwA |sis0-<< INTERNET >> > +---+ +-+ > > gwB's > - > gwB:24$ cat /etc/hostname.sis0 >inet 10.10.10.250 > 255.255.255.0 NONE > inet alias 1.2.3.65 255.255.255.192 NONE > gwB:25$ > > gwA's > - > gwA:511$ cat /etc/hostname.xl0 > inet 10.10.10.254 255.255.255.0 NONE > !/sbin/route add -net 1.2.3.64/26 10.10.10.250 > gwA:512$ cat /etc/hostname.sis0 > inet 1.2.3.2 255.255.255.192 NONE > gwA:513$ > > gwA:514$ sysctl -a net.inet.ip.forwarding > net.inet.ip.forwarding=1 > > Has anyone a clue ? > > TIA, > > -- > Fernando M. Braga
Odd routing problem ?
Hi, I'm facing an unusual problem with routing. I can access an internal server (with real IP) thru an OpenBSD gateway (gwA). Everything works when connection is initiated from the Internet. But gwB can't make its way back to the Internet. Every attempt to access any host on the Internet gets to gwA int_wireless, but doesn't goes out on ext_if. gwB can't even ping gwA external address 1.2.3.2. It makes no difference whether pf is enabled or not and, yes, net.inet.ip.forward is enabled. They're connected thru wireless bridges. I'll try to represent the network below: gwA has 3 interfaces: sis0 (external), vr0 (internal), and xl0 (int_wireless). gwB has 2 interfaces: sis0 (ext_wireless), and rl0 (internal). +---+ +-+ | gwB |sis0<< RADIO BRIDGES >>xl0| gwA |sis0-<< INTERNET >> +---+ +-+ gwB's - gwB:24$ cat /etc/hostname.sis0 inet 10.10.10.250 255.255.255.0 NONE inet alias 1.2.3.65 255.255.255.192 NONE gwB:25$ gwA's - gwA:511$ cat /etc/hostname.xl0 inet 10.10.10.254 255.255.255.0 NONE !/sbin/route add -net 1.2.3.64/26 10.10.10.250 gwA:512$ cat /etc/hostname.sis0 inet 1.2.3.2 255.255.255.192 NONE gwA:513$ gwA:514$ sysctl -a net.inet.ip.forwarding net.inet.ip.forwarding=1 Has anyone a clue ? TIA, -- Fernando M. Braga
Re: IPsec / routing problem in OpenBSD 3.7
> --- Quoting [EMAIL PROTECTED] on 2005/08/25 at 01:20 +0200: > > (can you try wrap your lines at a reasonable 72 chars?) Yup! Sorry.. > > > No, the rl0 gateway (PC_B) is 192.168.3.254. Client1 is .3.70, > > PC_B's internal network is, of course, 192.168.3.0/24. > > Oops, I should've seen that 3.70 was an ARP entry. It's odd that the > host route for .3.254 is missing through... > > >So, you are telling me what I need is actually a Phase 2 connection, > > so *everything* going through 10.0.0.1 <-> 10.0.0.6 gets encrypted? Let > > me go through some documentation first, in case I'll come back to you > > for this one. > > Well which of those ipsec flows above would match packets from 10.0.0.1 > to 10.0.0.6? Neither. You need to setup another phase-2 connection for these > hosts/networks. > > >Concerning issues 1) and 2), it seems as if, as soon as I start > > isakmpd, the 192.168.3.254 interface starts behaving like a bridge, > > since instead of replying itself it just passes on the packet to > > 10.0.0.6. Perhaps the routing gets screwed up, and it won't behave > > just by killing isakmpd and a "ipsecadm flush", you also need to flush > > the routing table (although I couldn't find any suspect entry that would > > account for this behaviour). > I'll be honest, I've never setup a phase-2 connection using a default > route so I've not seen this type of behavior. It seems though that the > icmp reply from .3.254 is matching the ipsec flow 192.168.3/24 -> 0/0 > and is therefor being punted to 10.0.0.1. When you ping 10.0.0.6, there > is no matching ipsec flow and so you don't see this behavior. > I am *really* scratching my head now. There must be something going on with my setup. Now, if I reboot PC_B and simply run a tcpdump on rl0, rl1 or enc0--you name it--even without running isakmpd on either PC_A or PC_B, I get nothing. I mean, nothing at all, just the usual tcpdump: listening on rl0, link-type EN10MB Nothing in /var/log/messages, nothing in dmesg. Oh, between one of my several reboots, I ran isakmpd and then stopped the process on both PC_A and PC_B and flushed the SA's. Then, everytime I tried to tcpdump on any interface, I got a "Failed to open bpf device for ..." error mesassge. Tried searching the 'net without results. Had to reboot again. Have you got any clue to what is happening here? --- LAST MINUTE UPDATE: in despair, I tried a PTP reboot (Pull The Plug). As soon as the machine rebooted, I tried (successfully, this time) to tcpdump on an interface. Then I tried the other interface, but nothing. So I tried the first interface again. Again, nothing. It seems tcpdump is behaving as a one-time command on my system. Weird thing, tcpdump isn't working, but I can access the Internet from my Client1 machine without problems. Later I'll try changing the cards. Perhaps half of my initial problem is actually a hardware issue, what do you think? Perhaps I should post the dmesg and start a new thread? --- MORE UPDATES: I took a break, since the connection was shaky and I wasn't able to send this message before. So I tried another thing. On PC_A, I re-enabled the line in pf that NATs the 10.0.0.0/29 network (between PC_A and PC_B, as you might recall). I can't believe what I'm seeing: as soon as I re-enable NAT, tcpdump starts working again. I disable NAT (again, only on 10.0.0.0, not on the 192.168.3.0/24--that's always on) and no more tcpdumps. What I can't figure out is what NAT has to do with this: i mean, my Client1 machine was merrily pinging all the time, so obviously something is going through the rl0 and rl1 interfaces, but it is not displayed. ... Rob Libero Flat, sempre a 4 Mega a 19,95 euro al mese! Abbonati subito su http://www.libero.it
Re: IPsec / routing problem in OpenBSD 3.7
--- Quoting [EMAIL PROTECTED] on 2005/08/25 at 01:20 +0200: (can you try wrap your lines at a reasonable 72 chars?) > No, the rl0 gateway (PC_B) is 192.168.3.254. Client1 is .3.70, PC_B's > internal network is, of course, 192.168.3.0/24. Oops, I should've seen that 3.70 was an ARP entry. It's odd that the host route for .3.254 is missing through... >So, you are telling me what I need is actually a Phase 2 connection, so > *everything* going through 10.0.0.1 <-> 10.0.0.6 gets encrypted? Let me go > through some documentation first, in case I'll come back to you for this one. Well which of those ipsec flows above would match packets from 10.0.0.1 to 10.0.0.6? Neither. You need to setup another phase-2 connection for these hosts/networks. >Concerning issues 1) and 2), it seems as if, as soon as I start isakmpd, > the 192.168.3.254 interface starts behaving like a bridge, since instead of > replying itself it just passes on the packet to 10.0.0.6. Perhaps the routing > gets screwed up, and it won't behave just by killing isakmpd and a "ipsecadm > flush", you also need to flush the routing table (although I couldn't find > any suspect entry that would account for this behaviour). I'll be honest, I've never setup a phase-2 connection using a default route so I've not seen this type of behavior. It seems though that the icmp reply from .3.254 is matching the ipsec flow 192.168.3/24 -> 0/0 and is therefor being punted to 10.0.0.1. When you ping 10.0.0.6, there is no matching ipsec flow and so you don't see this behavior. .joel
Re: IPsec / routing problem in OpenBSD 3.7
> --- Quoting [EMAIL PROTECTED] on 2005/08/24 at 18:35 +0200: > > 1) From Client1, I cannot ping its default gateway (.3.254) anymore. No > > ping replies. ssh connection is frozen. > > What machine and interface is .3.254 on? From the information below it does > not look like it's on PC_B. PC_B is .3.70. > No, the rl0 gateway (PC_B) is 192.168.3.254. Client1 is .3.70, PC_B's internal network is, of course, 192.168.3.0/24. sis0 --- ADSL MODEM | *PC_A* sis2 --- AP <- WiFi -> AP --- rl1 *PC_B* rl0 --- Client1 | sis1 --- 192.168.0.0/24 LAN I should have written it more clearly, sorry about that. > > 2) If I run a tcpdump -i rl1, I see that the pings from Client1 to PC_B are > > *routed* to PC_A!! Of course, PC_A doesn't know what to do with them; > > something is getting back, however (encrypted) : > > # tcpdump -i rl1 > > 17:54:15.803747 esp 10.0.0.6 > 10.0.0.1 spi 0x1F3A4307 seq 70 len 132 (DF) > > 17:54:15.810208 esp 10.0.0.1 > 10.0.0.6 spi 0x8A4C7C72 seq 58 len 132 (DF) > > Doubtful. You have no idea what packets are encapsulated here. Do your > sniffing on enc0 instead. > I will certainly try that and let you know. However, I'm quite confident that what I'm seeing going out of 10.0.0.6 and back from 10.0.0.1 are the pings originating from Client1 (192.168.3.70) to PC_B's internal interface (.3.254). I say this because 1) Client1 os the only machine behind PC_B 2) traffic to and fro 10.0.0.1 starts when I start pinging and stops accordingly and 3) I booted Client1 off DSL (Damn Small Linux, not the digital line!) instead of Winxxx. At least this way Client1 should behave the way I want it to instead of sending packets more or less at random. Also keep in mind that .3.254 doesn't reply to the pings when isakmpd is running. > > 6) Not all of PC_B 's traffic is going through the tunnel; for example, DNS > > queries are still in clear: > > netstat -rnf encap is your friend. You are not building a phase-2 > connection that includes 10.0.0.x so no encryption for you. Same > reasoning applies to your ping from 10.0.0.1 to .6. > Mmmmh... I'm getting lost. I am re-posting the netstat from my original message (they were buried at the very end, together with other infos): On PC_A (when isakmpd is running, of course): # netstat -r -f encap Routing tables Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.3/24 0 0/00 0 10.0.0.6/50/use/in 0/00 192.168.3/24 0 0 10.0.0.6/50/require/out On PC_B: # netstat -r -f encap Routing tables Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 0/00 192.168.3/24 0 0 10.0.0.1/50/use/in 192.168.3/24 0 0/00 0 10.0.0.1/50/require/out Does it look OK or am I missing something here? So, you are telling me what I need is actually a Phase 2 connection, so *everything* going through 10.0.0.1 <-> 10.0.0.6 gets encrypted? Let me go through some documentation first, in case I'll come back to you for this one. Concerning issues 1) and 2), it seems as if, as soon as I start isakmpd, the 192.168.3.254 interface starts behaving like a bridge, since instead of replying itself it just passes on the packet to 10.0.0.6. Perhaps the routing gets screwed up, and it won't behave just by killing isakmpd and a "ipsecadm flush", you also need to flush the routing table (although I couldn't find any suspect entry that would account for this behaviour). Do you thing the 1)-2) and the 6) issues are somehow related? --- Rob 6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero! Scaricalo su INTERNET GRATIS 6X http://www.libero.it
Re: IPsec / routing problem in OpenBSD 3.7
--- Quoting [EMAIL PROTECTED] on 2005/08/24 at 18:35 +0200: > 1) From Client1, I cannot ping its default gateway (.3.254) anymore. No ping > replies. ssh connection is frozen. What machine and interface is .3.254 on? From the information below it does not look like it's on PC_B. PC_B is .3.70. > 2) If I run a tcpdump -i rl1, I see that the pings from Client1 to PC_B are > *routed* to PC_A!! Of course, PC_A doesn't know what to do with them; > something is getting back, however (encrypted) : > # tcpdump -i rl1 > 17:54:15.803747 esp 10.0.0.6 > 10.0.0.1 spi 0x1F3A4307 seq 70 len 132 (DF) > 17:54:15.810208 esp 10.0.0.1 > 10.0.0.6 spi 0x8A4C7C72 seq 58 len 132 (DF) Doubtful. You have no idea what packets are encapsulated here. Do your sniffing on enc0 instead. > 6) Not all of PC_B 's traffic is going through the tunnel; for example, DNS > queries are still in clear: netstat -rnf encap is your friend. You are not building a phase-2 connection that includes 10.0.0.x so no encryption for you. Same reasoning applies to your ping from 10.0.0.1 to .6. .joel
IPsec / routing problem in OpenBSD 3.7
Hello! I'm having troubles with IPsec, but I'm not really sure whether it's an IPsec issue, a routing problem or just that I'm missing something big, very big... So any help is more than welcome! Here's the setup: PC_A is acting as a NAT gateway with three network cards. sis0 goes to an ADSL modem, sis1 talks to the local internal network (192.168.0.0/24). I have another office on the other side of the road with its own network (192.168.3.0/24 on rl0), gateway is 192.168.3.254 (PC_B). The rl1 card (10.0.0.6) is connected to a WiFi client whis in turn is bridged to a WiFi AP and finally to the sis2 card (10.0.0.1) on PC_A. sis0 --- ADSL MODEM | *PC_A* sis2 --- AP <- WiFi -> AP --- rl1 *PC_B* rl0 --- Client1 | sis1 --- 192.168.0.0/24 LAN Perhaps you already see where I'm going: I need to secure the connection between PC_A (on its 10.0.0.1 interface) and everything that's going to PC_B and to the LAN behind it (192.168.3.254). No, I don't need to tunnel the two subnets (192.168.0.0 and .3.0) together. They can live separated, as far as the remote office LAN (.3.0) can access the server and access the Internet. Both PC_A and PC_B are running on OpenBSD 3.7. So, I boot up PC_B and manually add the default route (it's fresh out of an install, so I still do it by hand): # route add 0/0 10.0.0.1 # route show -inet Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default10.0.0.1 UGS 09 - rl1 10.0.0.0/29link#2 UC 00 - rl1 10.0.0.1 00:09:5b:XX:XX:XX UHLc05 - rl1 loopback localhost UGRS00 33224 lo0 localhost localhost UH 00 33224 lo0 192.168.3/24 link#1 UC 00 - rl0 192.168.3.70 00:50:fc:XX:XX:XX UHLc0 309 - rl0 BASE-ADDRESS.MCAST localhost URS 00 33224 lo0 PLEASE NOTE : I posted all configuration info at the end of the message Next, Client1 can ping (obviously!) its default gateway (192.168.3.254), the rl1 card (10.0.0.6), the machine on the other side of the road (10.0.0.1 and 192.168.0.254) and, of course, google.com. Yes, there are two separate NAT rules (one for each internal network) and yes, PC_A has the routes to the remote network 192.168.3.0/24. So far, so good. Now I start isakmpd on both machines. This is what happens: 1) From Client1, I cannot ping its default gateway (.3.254) anymore. No ping replies. ssh connection is frozen. 2) If I run a tcpdump -i rl1, I see that the pings from Client1 to PC_B are *routed* to PC_A!! Of course, PC_A doesn't know what to do with them; something is getting back, however (encrypted) : # tcpdump -i rl1 17:54:15.803747 esp 10.0.0.6 > 10.0.0.1 spi 0x1F3A4307 seq 70 len 132 (DF) 17:54:15.810208 esp 10.0.0.1 > 10.0.0.6 spi 0x8A4C7C72 seq 58 len 132 (DF) 3) If Client1 pings 192.168.0.254 (on PC_A) or any other machine in PC_A's internal subnet, I get replies (encrypted through the tunnel). 4) If Crrlient1 pings www.google.com, I get replies (encrypted). 5) If I ssh on PC_A (10.0.0.1) and from there ping 10.0.0.6, the pings are unencrypted: 18:04:28.631809 10.0.0.1 > 10.0.0.6: icmp: echo request 18:04:28.631898 10.0.0.6 > 10.0.0.1: icmp: echo reply But I guess this was to be expected according to the way I set up the tunnel. 6) Not all of PC_B 's traffic is going through the tunnel; for example, DNS queries are still in clear: tcpdump: listening on rl1, link-type EN10MB 18:09:53.547812 esp 10.0.0.6 > 10.0.0.1 spi 0x33FDCE18 seq 84 len 148 (DF) [tos 0x10] 18:09:53.555414 esp 10.0.0.1 > 10.0.0.6 spi 0xFB1721D2 seq 64 len 100 (DF) [tos 0x10] 18:09:53.557740 esp 10.0.0.1 > 10.0.0.6 spi 0xFB1721D2 seq 65 len 148 (DF) [tos 0x10] 18:09:53.558698 esp 10.0.0.6 > 10.0.0.1 spi 0x33FDCE18 seq 85 len 100 (DF) [tos 0x10] 18:09:54.135727 10.0.0.6.27192 > ns3.XXX.domain: 40783+ PTR? 1.0.0.10.in-addr.arpa. (39) 18:09:54.164014 esp 10.0.0.6 > 10.0.0.1 spi 0x33FDCE18 seq 86 len 148 (DF) [tos 0x10] 18:09:54.175462 esp 10.0.0.1 > 10.0.0.6 spi 0xFB1721D2 seq 66 len 148 (DF) [tos 0x10] 18:09:54.176541 esp 10.0.0.6 > 10.0.0.1 spi 0x33FDCE18 seq 87 len 100 (DF) [tos 0x10] 18:09:54.18 esp 10.0.0.1 > 10.0.0.6 spi 0xFB1721D2 seq 67 len 180 (DF) [tos 0x10] 18:09:54.186064 10.0.0.1 > 10.0.0.6: icmp: echo request 18:09:54.186149 10.0.0.6 > 10.0.0.1: icmp: echo reply 18:09:54.186561 esp 10.0.0.6 > 10.0.0.1 spi 0x33FDCE18 seq 88 len 100 (DF) [tos 0x10] 18:09:54.189521 ns3.tin.it.domain > 10.0.0.6.27192: 40783 NXDomain* 0/1/0 (99) 18:09:54.191344 10.0.0.6.30665 > ns3.XXX.domain: 59489+ PTR? 6.0.0.10.in-addr.arpa. (39) 18:09:54.195008 esp 10.0.
