Re: Weird routing problem on simple CARP setup

[BARDOU Pierre]

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

[Stuart Henderson]

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

[Tom Smyth]

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

[BARDOU Pierre]

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

[Stefan Sperling]

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

[BARDOU Pierre]

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

[Erik van Westen]

-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

[Markus Rosjat]

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

[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 .

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

[Markus Rosjat]

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

[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.

> 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

[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

--
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

[R0me0 ***]

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

[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

[Mike Larkin]

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

[Denis Fondras]

> 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

[Leo Unglaub]

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

[Leo Unglaub]

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

[Mischa Peters]

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

[Leo Unglaub]

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

[Denis Fondras]

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

[Karsten Horsmann]

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

[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

vmd: routing problem

[Leo Unglaub]

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

Pf routing problem

[Leonardo M . Ramé]

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: Pf routing problem

[Claudio Jeker]

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

Re: Pf routing problem

[Leonardo M . Ramé]

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

[Leonardo M . Ramé]

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

routing problem

[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

[Nick Holland]

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.

Re: routing problem

[pavel pocheptsov]

what settings on client/home side?
B ipconfig /all, route print..etc


28 Q
P5P=QQP1QQ 2011, 11:18 PQ Wesley M. open...@e-solutions.re:
 
 
  
  
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

[Wesley M.]

On Wed, 28 Sep 2011 06:49:59 -0400, Nick Holland
n...@holland-consulting.net 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---ADSL_ROUTER---OpenBSD_PF---sis1---LAN---TS_server,ISP_router

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

[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


On Wed, 28 Sep 2011 15:05:52 +0400, pavel pocheptsov
lilit-aibo...@mail.ru wrote:
 what settings on client/home side?
 B ipconfig /all, route print..etc
 
 
 28 Q
P5P=QQP1QQ 2011, 11:18 PQ Wesley M.
open...@e-solutions.re:
  
  
   
   
 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

[Stuart Henderson]

On 2011-09-28, Nick Holland n...@holland-consulting.net 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

[Stuart Henderson]

On 2011-09-28, Wesley M. open...@e-solutions.re 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[2]: routing problem

[pavel pocheptsov]

28 Q
P5P=QQP1QQ 2011, 15:28 PQ Wesley M. open...@e-solutions.re:
 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

[Wesley M.]

On Wed, 28 Sep 2011 15:42:05 +0400, pavel pocheptsov
lilit-aibo...@mail.ru wrote:
 28 Q
P5P=QQP1QQ 2011, 15:28 PQ Wesley M.
open...@e-solutions.re:
 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: routing problem with 2nd default route via ipsec

[Axel Rau]

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

routing problem with 2nd default route via ipsec

[Axel Rau]

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=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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

[Gregory Edigarov]

On Thu, 28 Jul 2011 13:23:02 +0200
Axel Rau axel@chaos1.de 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

Re: routing problem with 2nd default route via ipsec

[Axel Rau]

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

routing problem

[Matt S]

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

[Claudio Jeker]

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

Re: routing problem

[Jussi Peltola]

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

[Christian Taube]

Am Fri, 9 Jul 2010 14:19:42 -0700
schrieb Matt S maschwa...@gmail.com:

 [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

[Matt Schwartz]

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 pe...@pelzi.net 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.

routing problem

[Federico]

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

[(private) HKS]

On Fri, Feb 20, 2009 at 6:34 AM, Federico deepb...@fastwebnet.it 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

Re: routing problem

[Charlie Clark]

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-miscm=120665186412690w=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

routing problem

[Charlie Clark]

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

[Daniel Anderson]

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-miscm=120665186412690w=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,

VPN routing problem

[Toni Mueller]

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

[Layne Evans]

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

Difficult routing problem

[Layne Evans]

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: Difficult routing problem

[Dave Anderson]

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]

Re: Difficult routing problem

[Thomas Schoeller]

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: nat or routing problem? SOLVED

[Mitja]

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?

[Mitja]

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]

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?

[Aleksandar Milosevic]

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?

[Rod.. Whitworth]

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 umop apisdn from up over?

Re: nat or routing problem?

[Mitja]

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?

[Mitja]

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.confsektion=5arch=apropos=0manpath=OpenBSD+4.0
and did not found anything usefull.

I'm stuck. Any ideas?


Regards,
Mitja

Re: nat or routing problem?

[Joel Goguen]

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]

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?

[Aleksandar Milosevic]

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?

[Mikael Fridh]

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

nat or routing problem?

[Mitja]

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: WDC WD2500KS-00MJB0
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: WDC WD2500KS-00MJB0
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: TEAC, CD-224E-N, 1.AA 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 

Re: nat or routing problem?

[Andreas Bihlmaier]

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:
snip

Regards,
ahb

Re: IPSec routing problem when using UDP

[David Bryan]

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

[Martín Coco]

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.

IPSec routing problem when using UDP

[Martín Coco]

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.

Routing problem?

[Jonas Lindskog]

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?

[Jason Dixon]

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

Re: Routing problem?

[Melameth, Daniel D.]

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: Odd routing problem ?

[Fernando Braga]

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 ?

[Fernando Braga]

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  10  -   sis0
1.2.3.1  0:60:2e:0:a4:99 

Odd routing problem ?

[Fernando Braga]

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: Odd routing problem ?

[Bryan Irvine]

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

Re: Odd routing problem ?

[Joachim Schipper]

(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: IPsec / routing problem in OpenBSD 3.7

[[EMAIL PROTECTED]]

 --- 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

IPsec / routing problem in OpenBSD 3.7

[[EMAIL PROTECTED]]

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.0.1  10.0.0.6 spi 0xFB1721D2 seq 68 len 196 (DF) [tos 
0x10]
18:09:54.196155 esp 10.0.0.6  10.0.0.1 spi 0x33FDCE18 seq 89 len 100 (DF) [tos

Re: IPsec / routing problem in OpenBSD 3.7

[j knight]

--- 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