ty issues if I tried to connect with non-OpenBSD
clients, since there are more protocols at work. But the upsides are
that it's architecturally clean (being logically equivalent to just
plugging the client computer's Ethernet cable into the server's
Ethernet network) and there would be no NDP issues because the NDP
messages would travel up and down the tunnel so the client could
handle them automatically. This approach appears to be documented
in the man page for etherip(4), but I haven't actually tried to get
that approach working.
Thanks again, everyone, and I hope you have a nice week.
Anthony Coulter
et
the same policy-specific tag that the tunnnel routes get. There are
other routing messages that I haven't even touched yet. Whether I
continue with all the other routes depends on what the mailing list
says about what's likely to be accepted. What matters to me is that
I h
-routed /56 subnet and start installing static routes all
through your network"? Or should it instead be: "For small networks,
you can set up a VPN using iked.conf alone"? It really seems like the
latter approach makes more sense. What am I missing? Why is going out
and getting a larger subnet from my ISP a better way to connect a
laptop to my VPN than just proxying the neighbor solicitations?
Thanks,
Anthony Coulter
dn't
do it as cleanly as an established OpenBSD developer. This way,
everyone wins: I can stop running my shell script as a daemon with root
privileges, other users (including Zack Newman, who apparently has the
same use case I do) benefit from the code updates, and some lucky
developer gets to have a really nice dinner. I also get to feel like I
contributed something useful to my favorite operating system.
Regards,
Anthony Coulter
to this, too.
That said, I repeat my offer of $200 if you (or someone else with
OpenBSD commit rights) can automate the process of enabling and
disabling NDP proxying for responder-assigned IPv6 addresses. I am
firmly convinced that this is a good idea because my VPN setup was
unusable until I tried "ndp -s".
> --
> Please keep replies on the mailing list.
Oops, Tobias' reply included me on the To: line so I assumed I was
supposed to do the same. This reply is to the misc list only.
Thanks,
Anthony Coulter
OK, I've sorted out my network issues server but it turns out that I
was misinterpreting the tcpdump output on my VPS. When an external
computer tries to ping my client's virtual IP address, the VPS's
gateway router is *not* forwarding the pings to my server where they
can be shoved into the IPsec
main, so I would expect the same routing rules to
apply to both.
=== In summary ===
For all this mess of detail, I think I have only two problems:
1. Why does my client have only one security association and zero
flows? I suspect that this is the cause of all of my other issues
with the tunnel.
2. Why does the server route packets over the tunnel only when they
originate on the server itself? (The ip6.forwarding sysctl is
enabled---the problem is that it wants to route these packets
onto the local link, not that it refuses to route at all.)
Does anybody have any thoughts on what I'm doing wrong?
Thanks,
Anthony Coulter
7 matches
Mail list logo
